Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3_rc1 2016-08-11T12:10:27Z 2016-08-11T12:10:27Z Julian Andres Klode jak@debian.org 2016-08-11T12:05:04Z urn:sha1:f8b879c2c805e6d49d438cad877a1706e4ae56d2 This commit looks heavy. Most of that comes from the fact that the ordering of files in the translations changed with the switch to CMake. I could have gone the extra mile to figure out the original ordering and replicate it, but I have chosen to re-order everything by file and line number, as that's easier. 2016-08-11T12:00:20Z Julian Andres Klode jak@debian.org 2016-08-11T12:00:20Z urn:sha1:80c0c9b2980310c78bd9bc26b463c7e3ad7fdae3 This enhances commit b9e6db821a6ddbc5bf6a90c80c296d4e91283a63. Gbp-Dch: ignore 2016-08-11T00:19:31Z David Kalnischkies david@kalnischkies.de 2016-08-11T00:19:31Z urn:sha1:c21dab6848cbe90736a998cbec8050fdf5110dd7 With cmake using BUILDDIRECTORY at this place is not only as wrong as it was before, but it might not even work always copying the system provided one which might or might not be current and hence fails tests needing it to be current like ./test-apt-move-and-forget-manual-sections We don't want to always use the one from the source directory through either like in autopkgtests. Gbp-Dch: Ignore 2016-08-10T23:36:23Z David Kalnischkies david@kalnischkies.de 2016-08-10T23:36:23Z urn:sha1:0a7370ca91289db3d23d72aeac397edfe3dfb75b 2016-08-10T23:36:18Z David Kalnischkies david@kalnischkies.de 2016-08-10T23:36:18Z urn:sha1:6b3ddbd059c403efeb40d81c29f2cae6e8f5b1bf 2016-08-10T23:34:39Z David Kalnischkies david@kalnischkies.de 2016-08-06T20:54:31Z urn:sha1:0568d325ad8660a9966d552634aa17c90ed22516 With apts http transport supporting socks5h proxies and all the work in terms of configuration of methods based on the name it is called with it becomes surprisingly easy to implement Tor support equally (and perhaps even a bit exceeding) what is available currently in apt-transport-tor. How this will turn out to be handled packaging wise we will see in https://lists.debian.org/deity/2016/08/msg00012.html , but until this is resolved we can add the needed support without actively enabling it for now, so that this can be tested better. 2016-08-10T23:34:39Z David Kalnischkies david@kalnischkies.de 2016-08-06T11:53:05Z urn:sha1:8665dceb5cf2a197ae270b08066f05c8a2870223 Doing a direct connect to an .onion address (if you don't happen to use it as a local domain, which you shouldn't) is bound to fail and does leak the information that you do use Tor and which hidden service you wanted to connect to to a DNS server. Worse, if the DNS is poisoned and actually resolves tricking a user into believing the setup would work correctly… This does block also the usage of wrappers like torsocks with apt, but with native support available and advertised in the error message this shouldn't really be an issue. Inspired-by: https://bugzilla.mozilla.org/show_bug.cgi?id=1228457 2016-08-10T21:51:35Z David Kalnischkies david@kalnischkies.de 2016-07-28T07:13:24Z urn:sha1:28557f94578602f9ce0011501a2259bd98ab0688 With b4450f1dd6bca537e60406b2383ab154a3e1485f we dropped what we calculated here later on and now that we don't need it in the meantime either we can just skip the busy work by default and expect dpkg to do the right thing dropping also our little "last explicit configures" removal trick introduced in b4450f1dd6bca537e60406b2383ab154a3e1485f. This enables the last of a bunch of previously experimental options, some of them existing still, but are very special and hence not really worth documenting anymore (especially as it would need to be rewritten now entirely) which is why the documentation is nearly completely dropped. The order of configuration stanzas in the simulation code changes slightly as it isn't concerning itself with finding the 'right' order, but any order is valid anyhow as long as the entire set happens in the same call. 2016-08-10T21:51:34Z David Kalnischkies david@kalnischkies.de 2016-07-28T09:43:36Z urn:sha1:4326680d2ed23d597f45ca8872a7054368560acc If a planner lets actions to be figured out by dpkg in pending calls these actions aren't mentioned in a simulation. While that might be a good thing for debugging, it would be a change in behavior and especially if a planner avoids explicit removals could be confusing for users. As such we perform the same 'trick' as in the dpkg implementation by performing explicitly what would be done by the pending calls. To save us some work and avoid desyncs we perform a layer violation by using deb/ code in the generic simulation – and further we perform ugly dynamic_cast to avoid breaking the ABI for nothing; aptitude is the only other user of the simulation class according to codesearch.d.n and for that our little trick works. It just isn't working if you happen to extend pkgSimulate or otherwise manage to call the protected Go methods directly – which isn't very realistic/practical. 2016-08-10T21:51:34Z David Kalnischkies david@kalnischkies.de 2016-07-25T14:36:53Z urn:sha1:83e5cffc2015aa809acac84737756d292d7bf106 The user has to approve the removal of a crossgraded package as it might be needed to remove it (temporarily) in the process, but in most cases we can happily avoid it and let dpkg unpack over it skipping the remove. This has some effects on progress reporting and how deal with selections through which makes this a tiny bit complicated.