apt/apt-pkg, branch 1.4.5

Fix parsing of or groups in build-deps with ignored packages

2017-05-31T12:39:53Z

If the last alternative(s) of an Or group is ignored, because it does not match an architecture list, we would end up keeping the or flag, effectively making the next AND an OR. For example, when parsing (on amd64): debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386] => debhelper (>= 9), libnacl-dev | Which can cause python-apt to crash. Even worse: debhelper (>= 9), libnacl-dev [amd64] | libnacl-dev [i386], foobar => debhelper (>= 9), libnacl-dev [amd64] | foobar By setting the previous alternatives Or flag to the current Or flag if the current alternative is ignored, we solve the issue. LP: #1694697

Fix and avoid quoting in CommandLine::AsString

2017-03-19T13:32:59Z

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

Fix mistake in CHANGEPATH comment example

2017-03-13T20:44:53Z

It says SRCNAME_SRCVER, but the example just gives the SRCVER part. Reported-By: Nishanth Aravamudan (nacc) in #ubuntu-devel

Ignore \.ucf-[a-z]+$ like we do for \.dpkg-[a-z]+$

2017-03-07T16:33:54Z

This gets rid of warnings about .ucf-dist files Reported-By: Axel Beckert (on IRC)

Don't use -1 fd and AT_SYMLINK_NOFOLLOW for faccessat()

2017-02-11T21:17:08Z

-1 is not an allowed value for the file descriptor, the only allowed non-file-descriptor value is AT_FDCWD. So use that instead. AT_SYMLINK_NOFOLLOW has a weird semantic: It checks whether we have the specified access on the symbolic link. It also is implemented only by glibc on Linux, so it's inherently non-portable. We should just drop it. Thanks: James Clarke for debugging these issues Reported-by: James Clarke

Do not package names representing .dsc/.deb/... files

2017-02-10T22:12:52Z

In the case of build-dep and other commands where a file can be passed we must make sure not to normalize the path name as that can have odd side effects, or well, cause the operation to do nothing. Test for build-dep-file is adjusted to perform the vcard check once as "vcard" and once as "VCard", thus testing that this solves the reported bug. We inline the std::transform() and optimize it a bit to not write anything in the common case (package names are defined to be lowercase, the whole transformation is just for names that should not exist...) to counter the performance hit of the added find() call (it's about 0.15% more instructions than with the existing transform, but we save about 0.67% in writes...). Closes: #854794

add Auto-Built-Package to tagfile-order

2017-02-09T11:59:05Z

Added in dpkg commit 6c8203440bf443d3031ee2ab8485b16c1b6da3b6

algorithms: Fix typo: gental -> gentle

2017-01-30T23:57:58Z

Oh dear, nobody (or rather no tool) saw that yet... Gbp-Dch: ignore

Only merge acquire items with the same meta key

2017-01-28T13:06:29Z

Since the introduction of by-hash, two differently named files might have the same real URL. In our case, the files icons-64x64.tar.gz and icons-128x128.tar.gz of empty tarballs. APT would try to merge them and end with weird errors because it completed the first download and enters the second stage for decompressing and verifying. After that it would queue a new item to copy the original file to the location, but that copy item would be in the wrong stage, causing it to use the hashes for the decompressed item. Closes: #838441

avoid malloc if option whitelist is disabled (default)

2017-01-27T20:06:09Z

Config options are checked in various paths, so making "useless" memory allocations wastes time and can also cause problems like #852757. The unneeded malloc was added in ae73a2944a89e0d2406a2aab4a4c082e1e9da3f9. (We have no explicit malloc here – its std:string doing this internally)