<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test, branch 1.3_rc4</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=1.3_rc4</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=1.3_rc4'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2016-09-02T15:16:36Z</updated>
<entry>
<title>acquire: Use priority queues and a 3 stage pipeline design</title>
<updated>2016-09-02T15:16:36Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-06-15T21:13:43Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=2a440328ea19e9646a93f847dd9eff21e03ad16d'/>
<id>urn:sha1:2a440328ea19e9646a93f847dd9eff21e03ad16d</id>
<content type='text'>
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 -&gt; 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.
</content>
</entry>
<entry>
<title>CMake: test/libapt: Use a prebuilt GTest library if available</title>
<updated>2016-09-02T12:34:37Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-09-02T12:09:52Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=99ba7cc1901c761c97d67775f23858b86594f2ba'/>
<id>urn:sha1:99ba7cc1901c761c97d67775f23858b86594f2ba</id>
<content type='text'>
If a non-existing source directory is specified, try finding
the system gtest library. Debian derived distributions are
a bit strange because they only ship the source code and
not the library...
</content>
</entry>
<entry>
<title>support long keyid and fingerprint in gpgv's GOODSIG</title>
<updated>2016-09-01T17:24:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-09-01T16:55:20Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6dc85f53d92b9763a1509a6472227c54bc70b01d'/>
<id>urn:sha1:6dc85f53d92b9763a1509a6472227c54bc70b01d</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>tests: silence -Wmissing-declarations</title>
<updated>2016-09-01T14:13:32Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-09-01T06:49:22Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=d8a57c1953b876917a9deb098d1ef3d2b093f3dc'/>
<id>urn:sha1:d8a57c1953b876917a9deb098d1ef3d2b093f3dc</id>
<content type='text'>
Gbp-Dch: Ignore
Reported-By: gcc -Wmissing-declarations
</content>
</entry>
<entry>
<title>test-apt-cdrom: Fix for gnupg 2.1.15</title>
<updated>2016-09-01T09:00:10Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-09-01T08:57:49Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0343b48e06fb990ee15a020bc6716b1a5a984e14'/>
<id>urn:sha1:0343b48e06fb990ee15a020bc6716b1a5a984e14</id>
<content type='text'>
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.
</content>
</entry>
<entry>
<title>test/integration/test-srcrecord: Make executable</title>
<updated>2016-08-31T10:26:39Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-31T10:25:38Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=832f95f4d018f18ff7b3d0381206f25b5a4373a6'/>
<id>urn:sha1:832f95f4d018f18ff7b3d0381206f25b5a4373a6</id>
<content type='text'>
I actually tried to amend the previous commit, but apparently
I forgot to add the file mode change.

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>Fix segfault and out-of-bounds read in Binary fields</title>
<updated>2016-08-31T10:12:56Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-31T09:36:44Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ce6cd75dc367b92f65e4fb539dd166d0f3361f8c'/>
<id>urn:sha1:ce6cd75dc367b92f65e4fb539dd166d0f3361f8c</id>
<content type='text'>
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 =&gt; --binEnd
				      =&gt; 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 &gt; buffer = false, isspace_ascii(*binEnd) = true
		 =&gt; exit loop
                =&gt; binEnd remains 0
</content>
</entry>
<entry>
<title>test: Pass -d to dpkg-buildpackage</title>
<updated>2016-08-30T15:37:59Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-30T15:37:59Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9109c3c309e95a6d99a88f945f17c37e5c04c105'/>
<id>urn:sha1:9109c3c309e95a6d99a88f945f17c37e5c04c105</id>
<content type='text'>
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
</content>
</entry>
<entry>
<title>test, travis: Quieter testing with a new -qq mode</title>
<updated>2016-08-29T13:42:06Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>jak@debian.org</email>
</author>
<published>2016-08-19T18:37:28Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=30ea7a60404ee53393235827202968393951d106'/>
<id>urn:sha1:30ea7a60404ee53393235827202968393951d106</id>
<content type='text'>
Introduce a new -qq mode for our integration test framework,
and make travis use it.

The new -qq mode sets MSGLEVEL to 1. In MSGLEVEL=1, no messages
are generated for passed tests, and all testcase filenames are
printed in the same line.

Also install first in travis, do not ls the installed output
and run the install with chronic, so we only get output if it
failed.

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>don't loop on pinning pkgs from absolute debs by regex</title>
<updated>2016-08-29T07:22:25Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2016-08-28T20:56:17Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e950b7e2f89b5e48192cd469c963a44fff9f1450'/>
<id>urn:sha1:e950b7e2f89b5e48192cd469c963a44fff9f1450</id>
<content type='text'>
An absolute filename for a *.deb file starts with a /. A package with
the name of the file is inserted in the cache which is provided by the
"real" package for internal reasons. The pinning code detects a regex
based wildcard by having the regex start with /. That is no problem
as a / can not be included in a package name… expect that our virtual
filename package can and does.

We fix this two ways actually: First, a regex is only being considered a
regex if it also ends with / (we don't support flags). That stops our
problem with the virtual filename packages already, but to be sure we
also do not enter the loop if matcher and package name are equal.

It has to be noted that the creation of pins for virtual packages like
the here effected filename packages is pointless as only versions can be
pinned, but checking that a package is really purely virtual is too
costly compared to just creating an unused pin.

Closes: 835818
</content>
</entry>
</feed>
