Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.7.0_alpha1 2018-06-13T21:36:08Z 2018-06-13T21:36:08Z Julian Andres Klode julian.klode@canonical.com 2018-06-13T16:45:12Z urn:sha1:79f012bd09ae99d4c9d63dc0ac960376b5338b32 debSystem uses a reference counted lock, so you can acquire it multiple times in your applications, possibly nested. Nesting locks causes a fd leak, though, as we only increment the lock count when we already have locked twice, rather than once, and hence when we call lock the second time, instead of increasing the lock count, we open another lock fd. This fixes the code to check if we have locked at all (> 0). There is no practical problem here aside from the fd leak, as closing the new fd releases the lock on the old one due to the weird semantics of fcntl locks. 2018-05-28T15:59:35Z David Kalnischkies david@kalnischkies.de 2018-05-26T15:36:08Z urn:sha1:79b61ae7673eb6213493e2cb202f0d70c390932d Clock changes while apt is running can result in strange reports confusing (and amusing) users. Sadly, to keep the ABI for now the code is a bit more ugly than it would need to be. 2018-05-28T15:57:25Z David Kalnischkies david@kalnischkies.de 2018-05-28T15:02:17Z urn:sha1:484babb7d00f7550cbaa592b7cb0022d38217fad Commit d7c92411dc1f4c6be098d1425f9c1c075e0c2154 introduced a warning for non-existent files from components not mentioned in Components to hint users at a mispelling or the disappearance of a component. The debian-installer subcomponent isn't actively advertised in the Release file through, so if apt ends up in acquiring a file which doesn't exist for this component (like Translation files) apt would produce a warning: W: Skipping acquire of configured file 'main/debian-installer/i18n/Translation-en' as repository 'http://deb.debian.org/debian buster InRelease' doesn't have the component 'main/debian-installer' (component misspelt in sources.list?) We prevent this in the future by checking if any file exists from this component which results in the warning to be produced still for the intended cases and silence it on the d-i case. This could potentially cause the warning not to be produced in cases it should be if some marginal file remains, but as this message is just a hint and the setup a bit pathological lets ignore it for now. There is also the possibility of having no file present as they would all be 0-length files and being a "hidden" component, but that would be easy to workaround from the repository side and isn't really actively used at the moment in the wild. Closes: #879591 2018-05-24T13:04:22Z Julian Andres Klode jak@debian.org 2018-05-24T13:04:22Z urn:sha1:6eaeec549241677335813af78f394010e5b3eefb more volatile: build-dep foo.deb/release & show foo.deb See merge request apt-team/apt!14 2018-05-24T12:54:34Z Julian Andres Klode jak@debian.org 2018-05-24T12:54:34Z urn:sha1:b367f2d393fa95a386feb03a64d4bf5e32cc28a4 Don't force the same mirror for by-hash URIs See merge request apt-team/apt!15 2018-05-21T16:13:26Z Filipe Brandenburger filbranden@google.com 2018-03-07T22:15:33Z urn:sha1:f0c2263dd702d646722b749f7b7d278d15c18c55 When running with Debug::pkgAutoRemove=yes, explain why certain packages are being marked, either because they're marked essential/important or because they match the blacklist from APT::NeverAutoRemove. This should help troubleshoot cases where autoremove is not proposing removal of packages expected to be up for removal. Tested manually with `apt-get autoremove -o Debug::pkgAutoRemove=yes`. 2018-05-11T16:28:34Z David Kalnischkies david@kalnischkies.de 2018-01-25T19:52:31Z urn:sha1:97f0bb4a60f2a3eda093e015767211d5c3c21c32 Downloading from the same mirror we got a Release file from makes sense for non-unique URIs as their content changes between mirror states, but if we ask for an index via by-hash we can be sure that we either get the file we wanted or a 404 for which we can perform a fallback for which allows us to pull indexes from different mirror in parallel. 2018-05-11T16:28:29Z David Kalnischkies david@kalnischkies.de 2018-01-15T11:04:45Z urn:sha1:ed0e9eadeb3003f4f150da3c463b28cfa5e54b6f Individual items shouldn't concern themselves with these alternative locations, we can deal with this more efficiently within the infrastructure created for other alternative URIs now avoiding the need to implement this in each item. 2018-05-11T16:28:19Z David Kalnischkies david@kalnischkies.de 2018-01-13T23:07:20Z urn:sha1:2d6c6c8809c7b4c1a009df48387ba15066fda7e2 If we got a file but it produced a hash error, mismatched size or similar we shouldn't fallback to alternative URIs as they likely result in the same error. If we can we should instead use another mirror. We used to be a lot stricter by stopping all trys for this file if we got a non-404 (or a hash-based) failure, but that is too hard as we really want to try other mirrors (if we have them) in the hope that they have the expected and correct files. 2018-05-11T15:58:46Z David Kalnischkies david@kalnischkies.de 2018-04-11T10:45:38Z urn:sha1:c5e2fa2b772524c03b0c7f777ffea6f2485fe6ca With the advent of compressed files and especially with in-memory post-processed files the simple assumptions made in IsOk are no longer true. Worse, they are at best duplicates of checks performed by the cache generation (and validation) earlier and isn't used in too many places. It is hence best to simply get right of these calls instead of trying to fix them.