apt/test, branch 1.1.3

accept ../ on the cmdline as start for a deb file as well

2015-11-29T13:32:29Z

Regression of 14341a7ee1ca3dbcdcdbe10ad19b947ce23d972d. Reported-By: Julian Andres Klode

tests: fix typos, correct helpmsgs and test tests

2015-11-29T13:05:38Z

Git-Dch: Ignore

do not override exact targetrelease matches with lesser matches

2015-11-29T12:36:28Z

The relevant testcases are in test/integration/test-apt-get-source. There is a test for #731853 that is supposed to "ensure that apt will pick the higher version number" of 0.0.1 (stable) and 0.1 (stable). However, this works by pure chance, as simply reversing the order of the two insertsource lines makes the test fail. So #731853 isn't really fixed, yet. Actually, that's related to the problem I reported, as the underlying issue for both is the same: In the FindSrc function apt chooses a new 'best hit', if either * there is a target release and it matches the release of the package, * or the version of the package is higher than the last best hit. Consider having 1.0 (stable), 2.0 (unstable) and 1.5 (unstable), in this order. Looking for the version in stable, apt first selects 1.0, because the release matches the target release, but then subsequently selects 2.0, because the version is higher. Looking for the version in unstable, apt first selects 2.0, because the release matches the target release, but then subsequently selects 1.5, because the release also matches the target release. The correct way would be to choose a new 'best hit', if either * there is a target release and it matches the release of the package, * or there is no target release and the version is higher than the last best hit. Closes: 746412 Mail-Reference: <565A604B.7090104@googlemail.com> Mail-Archive: https://lists.debian.org/debian-devel/2015/11/msg00470.html

disable privilege-drop verification by default as fakeroot trips over it

2015-11-28T12:30:29Z

Dropping privileges is an involved process for code and system alike so ideally we want to verify that all the work wasn't in vain. Stuff designed to sidestep the usual privilege checks like fakeroot (and its many alternatives) have their problem with this through, partly through missing wrapping (#806521), partly as e.g. regaining root from an unprivileged user is in their design. This commit therefore disables most of these checks by default so that apt runs fine again in a fakeroot environment. Closes: 806475

tests: use id to get user/group instead of environment

2015-11-28T12:27:06Z

debci seems to have a cleaner environment now and even if not we could never guess nogroup, so figure it out properly via 'id'. Git-Dch: Ignore

outsmart gcc -O3 over-optimization in pkgCdrom::FindPackages

2015-11-27T21:22:21Z

Seems like a simpler workaround than forcing a lower optimization level just for this for all of apt. See also: https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1473674

slightly rephrase notice shown for insecure repositories

2015-11-25T14:20:10Z

Git-Dch: Ignore

show potentially arch-qualified fullname in 'apt show'

2015-11-21T17:15:22Z

We do not show the architecture as a dedicated field as this is rather technical information, but as packagename it makes sense to show the architecture as other part of apt will refer to it in this way.

review of new/changed translatable program strings

2015-11-21T17:04:29Z

Reference mail: https://lists.debian.org/debian-l10n-english/2015/11/msg00006.html

do not sent Last-Modified if we expect a changed file

2015-11-21T12:47:19Z

In 8d041b4f we made apt figure out based on the last Release file it has if it should request a file or not given that the hashes changed or not. So if we have a last Release file and do a request, do not sent a Last-Modified header as we expect a change so much that a non-change would indeed be an error. The Last-Modified header is therefore at best ignored by the server, so sending it is just wasted effort. In the worst case as time is a fragile thing the server decides against sending us an update with the idea that we already have the latest content, which we know for a fact that we haven't. Given that we sent less information to the server our request is on its own also less identifiable as coming from a returning or new user. The disadvantage is that if we end up getting an old index file after getting a new Release file from another mirror the old mirror will not be able to tell us 'Hit', but instead sends us the complete file we discard, but both lets us end up with the same error class in the end, so the difference isn't big in practice.