apt/apt-pkg/acquire-worker.cc, branch 1.4_beta3 Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4_beta3 2016-12-31T01:29:20Z do not generate Maximum-Size if we already have that field 2016-12-31T01:29:20Z David Kalnischkies david@kalnischkies.de 2016-12-23T11:36:16Z urn:sha1:8bab752d3beb2d7ce791bf93dd8b52cfb1f718b0 Any respective parser will do the right thing and grab the last value, but its better for style to generate that field only once. Gbp-Dch: Ignore Merge branch 'portability/freebsd' 2016-08-26T22:31:03Z Julian Andres Klode jak@debian.org 2016-08-26T22:31:03Z urn:sha1:6a68315e938eb2611806658828ecea86805822e7 Make root group configurable via ROOT_GROUP 2016-08-26T20:24:25Z Julian Andres Klode jak@debian.org 2016-08-25T14:25:00Z urn:sha1:6f1f3c9afdb6ade6a7be110b90c8fc9e603254cf This is needed on BSD where root's default group is wheel, not root. do fail on weakhash/loop earlier in acquire 2016-08-24T08:24:41Z David Kalnischkies david@kalnischkies.de 2016-08-24T07:47:48Z urn:sha1:2e2865ae53a65c00dd55a892d5b48458f3110366 The bugreport shows a segfault caused by the code not doing the correct magical dance to remove an item from inside a queue in all cases. We could try hard to fix this, but it is actually better and also easier to perform these checks (which cause instant failure) earlier so that they haven't entered queue(s) yet, which in return makes cleanup trivial. The result is that we actually end up failing "too early" as if we wouldn't be careful download errors would be logged before that process was even started. Not a problem for the acquire system, but likely to confuse users and programs alike if they see the download process producing errors before apt was technically allowed to do an acquire (it didn't, so no violation, but it looks like it to the untrained eye). Closes: 835195 check internal redirections for loops, too 2016-08-17T05:55:45Z David Kalnischkies david@kalnischkies.de 2016-08-14T10:13:59Z urn:sha1:18ccc85f02325ac87ee13bb96c92594fcfda5ea4 Now that we have the redirections loopchecker centrally in our items we can use it also to prevent internal redirections to loop caused by bugs as in a few instances we get into the business of rewriting the URI we will query by ourself as we predict we would see such a redirect anyway. Our code has no bugs of course, hence no practical difference. ;) Gbp-Dch: Ignore log with the failed item description, not with next try 2016-08-16T17:20:28Z David Kalnischkies david@kalnischkies.de 2016-08-14T07:51:56Z urn:sha1:850ad02657c096fb227b38ef6d691fcf20acd619 The failure handling frequently changes URI & Description of the failed item to try a slightly different combination which might work, but the logging of the failure happens only afterwards as the same failure handling decides if this is a critical error or not so we need a backup here instead of potentially new content. A purely cosmetic issue, but can still be confusing for humans. allow methods to be disabled and redirected via config 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-06T17:59:57Z urn:sha1:c9c910695185b59aa27b787c1a250497e47b492b To prevent accidents like adding http-sources while using tor+http it can make sense to allow disabling methods. It might even make sense to allow "redirections" and adding "symlinked" methods via configuration. This could e.g. allow using different options for certain sources by adding and configuring a "virtual" new method which picks up the config based on the name it was called with like e.g. http does if called as tor+http. detect redirection loops in acquire instead of workers 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-02T20:44:50Z urn:sha1:57401c48fadc0c78733a67294f9cc20a57e527c9 Having the detection handled in specific (http) workers means that a redirection loop over different hostnames isn't detected. Its also not a good idea have this implement in each method independently even if it would work suggest transport-packages based on established namescheme 2016-08-10T21:19:44Z David Kalnischkies david@kalnischkies.de 2016-08-01T15:52:55Z urn:sha1:d0ef571416e1ff6266c89e6285898d269768cf8f apt-transports not shipped in apt directly are usually named apt-transport-% with % being what is in the name of the transport. tor additional introduced aliases via %+something, which isn't a bad idea, so be strip the +something part from the method name before suggesting the installation of an apt-transport-% package. This avoids us the maintainance of a list of existing transports creating a two class system of known and unknown transports which would be quite arbitrary and is unfriendly to backports. add insecure (and weak) allow-options for sources.list 2016-06-22T12:05:01Z David Kalnischkies david@kalnischkies.de 2016-06-20T18:50:43Z urn:sha1:d03b947b0ce4f87d7d5cc48d4d274ab3bd0b289a Weak had no dedicated option before and Insecure and Downgrade were both global options, which given the effect they all have on security is rather bad. Setting them for individual repositories only isn't great but at least slightly better and also more consistent with other settings for repositories.