apt/test, branch 1.2.3

test: use our special downloaded dir for 'source' result

2016-02-10T13:17:06Z

Otherwise the test run as root fails seeing the W: Can't drop privileges for downloading as file 'foo_1.tar.gz' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) warning in a command which isn't supposed to warn. One trivial test, two fixups and still counting… Git-Dch: Ignore

accept any tarball compression in 814139 testcase

2016-02-10T12:50:40Z

Travis still uses a dpkg version which defaults to gz and as which compression is picked isn't all to important as long as one is just accept any. Git-Dch: Ignore

test that seeking to a position earlier in the file works

2016-02-10T12:31:12Z

This tests the fix for #812994, #813000 Gbp-Dch: ignore

get dpkg lock in build-dep if cache was invalid again

2016-02-10T12:03:00Z

Regression introduced in a249b3e6fd798935a02b769149c9791a6fa6ef16, which in the case of an invalid cache would build the first part unlocked and later pick up the (still unlocked) cache for further processing, so the system got never locked and apt would end up complaining about being unable to release the lock at shutdown. The far more common case of having a valid cache worked as expected and hence covered up the problem – especially as tests who would have noticed it are simulations only, which do not lock. Closes: 814139 Reported-By: Balint Reczey Reported-By: Helmut Grohne on IRC

test: Fix apt-key tests to work with current gpg 2.1

2016-02-04T17:13:05Z

avoid building dependency tree in 'source' command

2016-02-03T13:56:49Z

We don't need the dependencies for obvious reasons and we don't need the candidate version either, so building a pkgDepCache is wasted effort, which we can stop doing now that build-dep cleared the path.

use pkgCache::VS instead of pkgDepCache::VS()

2016-02-03T12:50:00Z

The later just calls the earlier, but the later needs the fullblown dependency cache to be initialized, which is a very costly operation and isn't done anymore that early in the run as we would need to throw away and rebuild it again after we got all the information about source pkgs. As we end up with a nullptr for the pkgDepCache, we use a slightly longer calling convention to make sure that we use the pkgCache directly, avoiding nullptr induced segfaults and costly operations. Git-Dch: Ignore Reported-By: Balint Reczey

support -- in architecture specs

2016-01-31T22:24:59Z

APT has a different understanding than dpkg (#748936) what matches and what doesn't match an architecture specification as it isn't converting back (and forward) to Debian triplets. That has to eventually be solved some way or the other, but until that happens we change the matching in apt so that porters can continue their work on non-gnu libc-ports even if policy doesn't specify that yet (and dpkg just supporting it "by accident" via triplets). The initial patch was reformatted, fixed in terms of patterns containing "any-any", dealing with expanding an arch without libc to gnu while a pattern expands libc to any, the parsedepends test was fixed (the new if's were inserted one step too early) and another test just for the specifications added. Closes: #812212 Thanks: Bálint Réczey for initial patch

test all redirection codes work as expected

2016-01-31T18:06:19Z

Git-Dch: Ignore

only warn about missing/invalid Date field for now

2016-01-27T15:39:52Z

The Date field in the Release file is useful to avoid allowing an attacker to 'downgrade' a user to earlier Release files (and hence to older states of the archieve with open security bugs). It is also needed to allow a user to define min/max values for the validation of a Release file (with or without the Release file providing a Valid-Until field). APT wasn't formally requiring this field before through and (agrueable not binding and still incomplete) online documentation declares it optional (until now), so we downgrade the error to a warning for now to give repository creators a bit more time to adapt – the bigger ones should have a Date field for years already, so the effected group should be small in any case. It should be noted that earlier apt versions had this as an error already, but only showed it if a Valid-Until field was present (or the user tried to used the configuration items for min/max valid-until). Closes: 809329