Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.4 2017-04-01T19:43:23Z 2017-04-01T19:43:23Z Julian Andres Klode jak@debian.org 2017-04-01T19:43:23Z urn:sha1:47e53fe58e28dc1a2fa0098c6705f380f37f5902 2017-04-01T19:36:50Z Julian Andres Klode jak@debian.org 2017-04-01T19:35:35Z urn:sha1:03196fc5039b96134a36a890c6cc6e269dbc1449 Reported-By: Niels Thykier on IRC Gbp-Dch: ignore 2017-03-19T14:08:08Z David Kalnischkies david@kalnischkies.de 2017-03-19T14:08:08Z urn:sha1:c89b22c285d6c4a3cb64689ff26e84af4d1477f2 We are in a dilemma here: The regression of sorts was introduced in 2013 with commit d8a8f9d7f0 allowing pkg modifiers for the upgrade commands. That calls the autoremover as a sideeffect through and with it comes the option to remove the garbage packages in these commands (similar to aptitude). Having the option on the commandline is no problem – people aren't going to request what they don't want (or so I hope), but the documentation explicitly states that this option only effects install/remove and mentions a config knob users might use and expect to not suddenly apply (especially without documentation) to more commands. Just reverting the commit is out of question, completely ignoring the option breaks the workflow of every user who happened to use --autoremove on the commandline for upgrade and expects that to work given that it was accepted and worked in a stable release. Changing the documentation to reflect reality while perhaps the simplest and cleanest option contradicts freeze and is a surprising change we tend to avoid like the plague while just leaving it be confuses all users who end up believing the documentation even if was different in the last 3 years. So what we do is a tricky compromise: The configuration option if read from a file does apply only for install/remove as documented, while if the option is encountered on the commandline it is accepted and applies to the upgrade which should make 99% of the users happy. The rest has to wait for us to figure out for buster how to get that documented and implemented in a saner way. Closes: #855891 2017-03-19T13:32:59Z David Kalnischkies david@kalnischkies.de 2017-03-19T12:53:33Z urn:sha1:2ce15bdeac6ee93faefd4b42b57f035bef80c567 In the intended usecase where this serves as a hack there is no problem with double/single quotes being present as we write it to a log file only, but nowadays our calling of apt-key produces a temporary config file containing this "setting" as well and suddently quoting is important as the config file syntax is allergic to it. So the fix is to ignore all quoting whatsoever in the input and just quote (with singles) the option values with spaces. That gives us 99% of the time the correct result and the 1% where the quote is an integral element of the option … doesn't exist – or has bigger problems than a log file not containing the quote. Same goes for newlines in values. LP: #1672710 2017-03-14T08:39:13Z Joe Dalton joedalton2@yahoo.dk 2017-03-10T07:44:48Z urn:sha1:c8ecf96594c7fad8781775590dafc302b49fe6a8 Closes: #856723 2017-03-13T20:44:53Z Julian Andres Klode jak@debian.org 2017-03-13T20:44:53Z urn:sha1:e6dddfec2552c798a820d31691d59928929c0905 It says SRCNAME_SRCVER, but the example just gives the SRCVER part. Reported-By: Nishanth Aravamudan (nacc) in #ubuntu-devel 2017-03-13T15:31:38Z Chris Lamb lamby@debian.org 2017-03-13T10:02:49Z urn:sha1:a9b56a0101628ac04aad0d4e50363b9c18566832 If one is attempting to create a reproducible ISO image we do not want to include the build system's kernel version, not only due to it breaking reproducibility, but it could be somewhat misleading and/or the wrong thing to put in this file anyway. Closes: #857632 2017-03-07T16:33:54Z Julian Andres Klode jak@debian.org 2017-03-07T16:33:54Z urn:sha1:5094697fe4b2459ff6f706a22006d3028369f3fa This gets rid of warnings about .ucf-dist files Reported-By: Axel Beckert (on IRC) 2017-02-22T15:03:03Z Julian Andres Klode jak@debian.org 2017-02-22T15:03:03Z urn:sha1:2c19feb4e6c046b97078fdfd3e6e5bd6442b13fe 2017-02-12T17:42:02Z Julian Andres Klode jak@debian.org 2017-01-22T18:52:19Z urn:sha1:f5e9be1da89725f9bf1915bdf86fdc4a77edf917 Ubuntu servers / Launchpad rejects uploads where debian/copyright is a symbolic link, and lintian warns about them. I think that's crazy, but I'm tired of having to work around this in SRUs, so let's just solve it by copying the file during clean: This way, it won't be in git, but it will be generated during the export by git-buildpackage.