Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.3 2016-09-18T12:17:17Z 2016-09-18T12:17:17Z Julian Andres Klode jak@debian.org 2016-09-18T11:24:35Z urn:sha1:708e2f1fe99e6f067292bc909f03f12c181e4798 If the dependency line does not contain spaces in the repository but does in the dpkg status file (because dpkg normalized the dependency list), the dpkg line might be longer than the line in the repository. If it now happens to be longer than 1024 characters, it would be skipped, causing the hashes to be out of date. Note that we have to bump the minor cache version again as this changes the format slightly, and we might get mismatches with an older src cache otherwise. Fixes Debian/apt#23 2016-09-07T12:00:38Z Julian Andres Klode jak@debian.org 2016-09-07T11:35:40Z urn:sha1:561a3557e7fa6c4ed693c3bb486d189a468a8080 Even if we only configure a single architecture, install dpkg, so dpkg can assert multi arch correctly. This also has the nice side effect of making single architecture and multiple architecture test cases more uniform. This fixes a regression from f878d3a862128bc1385616751ae1d78246b1bd01 ("test: Assert multi-arch in the chroot"). 2016-09-07T12:00:37Z Julian Andres Klode jak@debian.org 2016-09-07T11:23:26Z urn:sha1:c382e0dff11beb00632d67d9361831358a38e465 If we copied one of the existing status files, we might not have a trailing newline, so let's add one. Gbp-Dch: ignore 2016-09-07T08:21:01Z David Kalnischkies david@kalnischkies.de 2016-09-07T08:21:01Z urn:sha1:12b201da7c1d5e2beceae796151e4ebedc5bae97 Commit b60c8a89c281f2bb945d426d2215cbf8f5760738 improved the situation, but due to inconsistency mostly for planners, not for solvers. As the idea of hiding errors if we show another error is a bit scary (as the extern error might be a followup of our intern error, rather than the reason for our intern error as it is at the moment) we don't discard the errors, but if we got an extern error we show them directly removing them from the error list at the end of the run – that list will contain the extern error which hopefully gives us the best of both worlds. The problem itself is the same as before: The externals exiting before apt is done talking to them. Reported-By: Johannes 'josch' Schauer on IRC 2016-09-02T15:16:36Z Julian Andres Klode jak@debian.org 2016-06-15T21:13:43Z urn:sha1:2a440328ea19e9646a93f847dd9eff21e03ad16d Employ a priority queue instead of a normal queue to hold the items; and only add items to the running pipeline if their priority is the same or higher than the priority of items in the queue. The priorities are designed for a 3 stage pipeline system: In stage 1, all Release files and .diff/Index files are fetched. This allows us to determine what files remain to be fetched, and thus ensures a usable progress reporting. In stage 2, all Pdiff patches are fetched, so we can apply them in parallel with fetching other files in stage 3. In stage 3, all other files are fetched (complete index files such as Contents, Packages). Performance improvements, mainly from fetching the pdiff patches before complete files, so they can be applied in parallel: For the 01 Sep 2016 03:35:23 UTC -> 02 Sep 2016 09:25:37 update of Debian unstable and testing with Contents and appstream for amd64 and i386, update time reduced from 37 seconds to 24-28 seconds. Previously, apt would first download new DEP11 icon tarballs and metadata files, causing the CPU to be idle. By fetching the diffs in stage 2, we can now patch our contents and Packages files while we are downloading the DEP11 stuff. 2016-09-01T17:24:26Z David Kalnischkies david@kalnischkies.de 2016-09-01T16:55:20Z urn:sha1:6dc85f53d92b9763a1509a6472227c54bc70b01d In gpgv1 GOODSIG (and the other messages of status-fd) are documented as sending the long keyid. In gpgv2 it is documented to be either long keyid or the fingerprint. At the moment it is still the long keyid, but the documentation hints at the possibility of changing this. We care about this for Signed-By support as we detect this way if the right fingerprint has signed this file (or not). The check itself is done via VALIDSIG which always is a fingerprint, but there must also be a GOODSIG (as expired sigs are valid, too) found to be accepted which wouldn't be found in the fingerprint-case and the signature hence refused. 2016-09-01T09:00:10Z Julian Andres Klode jak@debian.org 2016-09-01T08:57:49Z urn:sha1:0343b48e06fb990ee15a020bc6716b1a5a984e14 gpg annoyingly changed its output and broke our test suite again by adding two extra lines about key type and issuer. Really annoying. Those lines also have more than one space after the colon, so let's use \s* there - and also change the other lines to support variable length whitespace in case gpg decides to break things there too. 2016-08-31T10:26:39Z Julian Andres Klode jak@debian.org 2016-08-31T10:25:38Z urn:sha1:832f95f4d018f18ff7b3d0381206f25b5a4373a6 I actually tried to amend the previous commit, but apparently I forgot to add the file mode change. Gbp-Dch: ignore 2016-08-31T10:12:56Z Julian Andres Klode jak@debian.org 2016-08-31T09:36:44Z urn:sha1:ce6cd75dc367b92f65e4fb539dd166d0f3361f8c If a Binary field contains one or more spaces before a comma, the code produced a segmentation fault, as it accidentally set a pointer to 0 instead of the value of the pointer. If the comma is at the beginning of the field, the code would create a binStartNext that points one element before the start of the string, which is undefined behavior. We also need to check that we do not exit the string during the replacement of spaces before commas: A string of the form " ," would normally exit the boundary of the Buffer: binStartNext = offset 1 ',' binEnd = offset 0 ' ' isspace_ascii(*binEnd) = true => --binEnd => binEnd = - 1 We get rid of the problem by only allowing spaces to be eliminated if they are not the first character of the buffer: binStartNext = offset 1 ',' binEnd = offset 0 ' ' binEnd > buffer = false, isspace_ascii(*binEnd) = true => exit loop => binEnd remains 0 2016-08-30T15:37:59Z Julian Andres Klode jak@debian.org 2016-08-30T15:37:59Z urn:sha1:9109c3c309e95a6d99a88f945f17c37e5c04c105 This works around an issue on Fedora where dpkg complains about missing build-essential: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native Gbp-Dch: ignore