Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.6_alpha1 2017-10-20T21:40:53Z 2017-10-20T21:40:53Z Julian Andres Klode jak@debian.org 2017-10-20T21:37:36Z urn:sha1:404dececf913d3c09368a73ca00aa8172dbf6865 tagfile-order.c: Add missing fields from dpkg 1.19 For binary packages, this is Build-Essential; for source packages, it is Description. test-bug-718329-...: Ignore control.tar.*, changes in dpkg 1.19 test-apt-extracttemplates: Fix for dpkg 1.19 2017-10-05T15:30:25Z David Kalnischkies david@kalnischkies.de 2017-08-01T13:22:09Z urn:sha1:012932793ba0ea9398a9acd80593bed8e77cfbfc gpg2 generates keyboxes by default and users end up putting either those or armored files into the trusted.gpg.d directory which apt tools neither expect nor can really work with without fortifying backward compatibility (at least under the ".gpg" extension). A (short) discussion about how to deal with keyboxes happened in https://lists.debian.org/deity/2017/07/msg00083.html As the last message in that thread is this changeset lets go ahead with it and see how it turns out. The idea is here simply that we check the first octal of a gpg file to have one of three accepted values. Testing on my machines has always produced just one of these, but running into those values on invalid files is reasonabily unlikely to not worry too much. Closes: #876508 2017-09-26T17:45:12Z David Kalnischkies david@kalnischkies.de 2017-09-26T17:45:12Z urn:sha1:7ea3c67f96e3bc82f86afe72d6c61308c92de515 APT used to parse only wellformed files produced by repository creation tools which removed empty files as pointless before apt would see them. Now that apt can be told to parse e.g. debian/control files directly, it needs to be a little more accepting through: We had this with comments already, now let it deal with the far more trivial empty fields. Closes: #875363 2017-09-26T17:32:15Z David Kalnischkies david@kalnischkies.de 2017-09-26T17:27:30Z urn:sha1:f3e34838d95132e5f318e85525326decbfb19e36 APT connects just fine to any .onion address given, only if the connect fails somehow it will perform checks on the sanity of which in this case is checking the length as they are well defined and as the strings are arbitrary a user typing them easily mistypes which apt should can be slightly more helpful in figuring out by saying the onion hasn't the required length. 2017-09-24T18:36:41Z Julian Andres Klode jak@debian.org 2017-09-24T18:33:49Z urn:sha1:5e770a07c8fd649340e83725f6d07b94c361e87c This automatically removes any old apt-transport-https, as apt now Breaks it unversioned. 2017-09-09T18:12:15Z Julian Andres Klode jak@debian.org 2017-09-03T12:38:58Z urn:sha1:8d23827be3043daf7fed1b86da1d41578889eaeb When writing a Sources files hashes that were already present in the .dsc were always copied through (or modified), even if disabled. Remove them instead when they are disabled, otherwise we end up with hashes for tarballs and stuff but not for dsc files (as the dsc obviously does not hash itself). Also adjust the tests: test-compressed-indexes relied on Files being present in showsrc, and test-apt-update-weak-hashes expected the tarball to be downloaded when an archive only has MD5 and we are requiring SHA256 because that used to work because the tarball was always included. Closes: #872963 2017-09-09T15:19:48Z David Kalnischkies david@kalnischkies.de 2017-08-28T11:22:58Z urn:sha1:8130f39cf085efcf34bee9e9ce89802b29bb9318 Commit e250a8d8d8ef2f8f8c5e2041f7645c49fba7aa36 implemented the fix and should have included already this testcase for it. Gbp-Dch: Ignore 2017-09-09T12:00:48Z Julian Andres Klode jak@debian.org 2017-09-09T12:00:11Z urn:sha1:4d4459a5548e82224aac778833625358c0801681 gpgv: WARNING: This key is not suitable for signing in --compliance=gnupg mode 2017-08-24T15:44:31Z Julian Andres Klode jak@debian.org 2017-08-24T15:44:31Z urn:sha1:427828d9638c9e5f3550820bd9d71da5d5a0909c It was broken because apt.conf.d was not readable, but that's where the architecture is defined... 2017-08-04T11:06:10Z David Kalnischkies david@kalnischkies.de 2017-07-28T16:20:14Z urn:sha1:d108e019d3ca74c31a1ab646ddef5c60744a5e7d If 'apt-ftparchive packages /path/to/files/' (or sources) is used the files to include in the generated index (on stdout) were included in the order in which they were discovered, which isn't a very stable order which could lead to indexes changing without actually changing content causing needless changes in the repository changing hashsums, pdiffs, rsyncs, downloads, …. This does not effect apt-ftparchive calls which already have an order defined via a filelist (like generate) which will still print in the order given by the filelist. Note that a similar effect can be achieved by post-processing index files with apt-sortpkgs. Closes: 869557 Thanks: Chris Lamb for initial patch & Stefan Lippers-Hollmann for testing