Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1 2015-11-25T14:20:10Z 2015-11-25T14:20:10Z David Kalnischkies david@kalnischkies.de 2015-11-22T14:09:50Z urn:sha1:add81166f8ecb194ab5cf881200ab9d890abea6c The manpages were fixed by Justin B Rye, lets deal with the rest now. Git-Dch: Ignore 2015-11-25T14:20:10Z Justin B Rye justin.byam.rye@gmail.com 2015-11-22T09:14:12Z urn:sha1:839603418384565a53d9aca7b23dbd7742e3ea77 Git-Dch: Ignore 2015-11-21T17:04:29Z Justin B Rye justin.byam.rye@gmail.com 2015-11-21T16:50:06Z urn:sha1:d04e44ac8177fc5b70ae0189bb5e437c2502f910 Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html 2015-11-21T12:47:19Z David Kalnischkies david@kalnischkies.de 2015-11-21T12:47:19Z urn:sha1:abd6af5a1ce2c20a5742c5c3182dfadce10367ca In 8d041b4f we made apt figure out based on the last Release file it has if it should request a file or not given that the hashes changed or not. So if we have a last Release file and do a request, do not sent a Last-Modified header as we expect a change so much that a non-change would indeed be an error. The Last-Modified header is therefore at best ignored by the server, so sending it is just wasted effort. In the worst case as time is a fragile thing the server decides against sending us an update with the idea that we already have the latest content, which we know for a fact that we haven't. Given that we sent less information to the server our request is on its own also less identifiable as coming from a returning or new user. The disadvantage is that if we end up getting an old index file after getting a new Release file from another mirror the old mirror will not be able to tell us 'Hit', but instead sends us the complete file we discard, but both lets us end up with the same error class in the end, so the difference isn't big in practice. 2015-11-20T08:46:18Z David Kalnischkies david@kalnischkies.de 2015-11-20T08:46:18Z urn:sha1:89497574da3dd40076d955efc936b54e76a8c59c Reported-By: codespell Git-Dch: Ignore 2015-11-19T23:54:07Z David Kalnischkies david@kalnischkies.de 2015-11-19T23:54:07Z urn:sha1:6789e01e9370b3b7f65d52138c5657eaa712b4d1 Out of memory and similar circumstanzas could cause MMap::Map to fail and especially the mmap/malloc calls in it. With some additional checking we can avoid segfaults and similar in such situations – at least in theory as if this is a real out of memory everything we do to handle the error could just as well run into a memory problem as well… But at least in theory (if MMap::Map is made to fail always) we can deal with it so good that a user actually never sees a failure (as the cache it tries to load with it fails and is discarded, so that DynamicMMap takes over and a new one is build) instead of segfaulting. Closes: 803417 2015-11-19T16:56:07Z David Kalnischkies david@kalnischkies.de 2015-11-19T15:19:15Z urn:sha1:6aef1942f441e6e667982b92802907026d8cc7c6 In ce1f3a2c we started warning about failing unlinking, which we consistently do for directories. That isn't a problem as directories usually aren't in the places we do want to clean up – with the potential exeception of "lost+found", so lets ignore it like we ignore our own partial/ subdirectory. Closes: 805424 2015-11-19T16:13:56Z David Kalnischkies david@kalnischkies.de 2015-11-19T12:28:17Z urn:sha1:bc7a59dded57338e9b5e523726b246dbdd4e0935 space-gapping: '-o option= value' That is a very old feature (straight from 1998), but it is super surprising if you try setting empty values and instead get error messages or a non-empty value as the next parameter is treated as the value – which could have been empty, so if for some reason you need a compatible way of setting an empty value try: '-o option="" ""'. I can only guess that the idea was to support '-o option value', but we survived 17 years without it, we will do fine in the future I guess. Similar is the case for '-t= testing' even through '-t testing' existed before and the code even tried to detect mistakes like '-t= -b' … all gone now. Technically that is as its removing a feature replacing it with another a major interface break. In practice I really hope for my and their sanity that nobody was using this; but if for some reaon you do: Remove the space and be done. I found the patch and the bugreport actually only after the fact, but its reassuring that others are puzzled by this as well and hence a thanks is in perfect order here as the patch is practical identical [expect that this one here adds tests and other bonus items]. Thanks: Daniel Hartwig for initial patch. Closes: 693092 2015-11-19T15:46:29Z David Kalnischkies david@kalnischkies.de 2015-11-18T18:31:40Z urn:sha1:514a25cbcd2babb2a9c4485fc7b9a4256b7f6ff3 In 0940230d we started dropping privileges for file (and a bit later for copy, too) with the intend of uniforming this for all methods. The commit message says that the source will likely fail based on the compressors already – and there isn't much secret in the repository content. After all, after apt has run the update everyone can access the content via apt anyway… There are sources through which worked before which are mostly single-deb (and those with the uncompressed files available). The first one being especially surprising for users maybe, so instead of failing, we make it so that apt detects that it can't access a source as _apt and if so doesn't drop (for all sources!) privileges – but we limit this to file/copy, so the uncompress which might be needed will still fail – but that failed before this regression. We display a notice about this, mostly so that if it still fails (e.g. compressed) the user has some idea what is wrong. Closes: 805069 2015-11-05T11:21:33Z David Kalnischkies david@kalnischkies.de 2015-11-05T00:51:44Z urn:sha1:f01f5d911d6a9731893865bb1ec617c5038add3e This 'ignores' the component Release files you can find in Debian alongside the binary-* directories, which isn't exactly a common usecase, but it worked before, so lets support it again as this isn't worse than a valid Release file which is unsigned. Git-Dch: Ignore