Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.1 2015-11-21T17:04:29Z 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-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: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-04T22:38:40Z urn:sha1:4453cfdcf42f7fe6859bb0fc6b310a2a391bee77 Limit the field length to a char to avoid bogus FF for utf-8 characters with the default length. Closes: 799123 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T17:49:52Z urn:sha1:ce1f3a2c616b86da657c1c796efa5f4d18c30c39 Unlinking /dev/null is bad, we shouldn't do that. Also, we should print at least a warning if we tried to unlink a file but didn't manage to pull it of (ignoring the case were the file is /dev/null or doesn't exist in the first place). This got triggered by a relatively unlikely to cause problem in pkgAcquire::Worker::PrepareFiles which would while temporary uncompressed files (which are set to keep compressed) figure out that to files are the same and prepare for sharing by deleting them. Bad move. That also shows why not printing a warning is a bad idea as this hide the error for in non-root test runs. Git-Dch: Ignore 2015-11-04T17:42:28Z David Kalnischkies david@kalnischkies.de 2015-11-02T15:02:44Z urn:sha1:cd46d4ebd33e74ee53bbc73dcdb7fe1d4d006558 The wrapping will fail in the best case and actually end up deleting /dev/null in the worst case. Given that there is no point in trying to write atomically to /dev/null as you can't read from it again just ignore these flags if higher level code ends up trying to use them on /dev/null. Git-Dch: Ignore 2015-11-04T17:04:04Z David Kalnischkies david@kalnischkies.de 2015-10-26T10:42:32Z urn:sha1:6079b276a959086ff18302cab752b6d7cfe5ad9f Its not as simple as I initially thought to abstract this enough to make it globally usable, so lets not pollute global namespace with this for now. Git-Dch: Ignore 2015-11-04T17:04:03Z David Kalnischkies david@kalnischkies.de 2015-10-25T11:35:00Z urn:sha1:2b0660b537581e9e65180e4cf1a94d763fd66847 -q is for logging and -qqq (old -qq) basically kills every output expect errors, so there should be a way of declaring a middleground in which the output of e.g. 'update' isn't as verbose, but still shows some things. The test framework was actually making use of by accident as it ignored the quiet level in output setup for apt before. Eventually we should figure out some better quiet levels for all tools… 2015-11-04T17:04:03Z David Kalnischkies david@kalnischkies.de 2015-10-24T20:43:37Z urn:sha1:e7e10e47476606e3b2274cf66b1e8ea74b236757 All mains pretty much do the same thing, so lets try a little harder to move the common parts into -private to have the real differences more visible. Git-Dch: Ignore