apt/test/integration, branch 1.2.8Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=1.2.82016-03-22T00:58:45Zhandle gpgv's weak-digests ERRSIG2016-03-22T00:58:45ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-22T00:26:29Zurn:sha1:08b7761a251a36fa65cbe022a86c51d7f091a88d
Our own gpgv method can declare a digest algorithm as untrusted and
handles these as worthless signatures. If gpgv comes with inbuilt
untrusted (which is called weak in official terminology) which it e.g.
does for MD5 in recent versions we should handle it in the same way.
To check this we use the most uncommon still fully trusted hash as a
configureable one via a hidden config option to toggle through all of
the three states a hash can be in.
properly check for "all good sigs are weak"2016-03-21T21:47:17ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-21T17:47:10Zurn:sha1:8fa99570816d3a644a9c4386c6a8f2ca21480329
Using erase(pos) is invalid in our case here as pos must be a valid and
derefenceable iterator, which isn't the case for an end-iterator (like
if we had no good signature).
The problem runs deeper still through as VALIDSIG is a keyid while
GOODSIG is just a longid so comparing them will always fail.
Closes: 818910
tests: reenable basic auth test and add @ in username2016-03-19T08:48:44ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-18T10:37:31Zurn:sha1:28b2efcb190edd97b802ac9055eaf417f141f724
On launchpad #1558484 a user reports that @ in the authentication tokens
parsing of sources.list isn't working in an older (precise) version. It
isn't the recommended way of specifying passwords and co (auth.conf is),
but we can at least test for regressions (and in this case test at all…
who was that "clever" boy disabling a test with exit……… oh, nevermind.
Git-Dch: Ignore
cachefile: Only set members that were initialized successfully2016-03-19T06:19:24ZJulian Andres Klodejak@debian.org2016-03-19T00:56:38Zurn:sha1:f40fdaa43271edf98b80c08e20f401b5da591501
Otherwise, things will just start failing later down the stack,
because (a) the lazy getters do not check if building was successful
and (b) any further getter call would return the invalid object
anyway.
Also initialize VS in pkgCache to nullptr by default.
Closes: #818628
test framework: Pass -n to lsof to speed up finding the https port2016-03-17T11:49:03ZJulian Andres Klodejak@debian.org2016-03-17T11:49:03Zurn:sha1:6970f6e6c73116e7c5b488eefe81cd4de98c9170
There is no point in resolving all addresses to their names, this
just seriously slows the setup phase down. So just pass -n to not
resolve names anymore.
Gbp-Dch: ignore
test-acquire-same-file-multiple-times: Run failing test up to 10 times2016-03-17T11:32:19ZJulian Andres Klodejak@debian.org2016-03-17T11:28:51Zurn:sha1:c030cc931ebfb7228801e5b63f3fc32852825da2
This should make the test less flaky and hopefully fix the failure
on Ubuntu's armhf CI nodes.
Gbp-Dch: ignore
Make test-apt-download-progress less flaky2016-03-17T10:59:32ZJulian Andres Klodejak@debian.org2016-03-17T10:56:31Zurn:sha1:dea8713142383aed6906f93e773329f8487d39b1
The test is a bit flaky. In order to get it less flaky, reduce
the speed in each run. To compensate for issues, start with a
higher speed level. Also increase the number of runs to 10.
Furthermore, http get the same multiple-run loop, and the log
files are changed to indicate the protocol being tested, as it's
not obvious which one fails if it fails in quiet mode.
Gbp-Dch: ignore
do not strip epochs from state version strings2016-03-16T22:29:45ZDavid Kalnischkiesdavid@kalnischkies.de2016-03-16T21:32:48Zurn:sha1:a38cec81d349525c447004ef8fe9dc942c8bd9bb
The epoch stripping in this code is done since day one, but in other
places we show a version epochs are not stripped. If epochs are present
in packages they tend to be an important information which we can't just
drop and especially can't drop "sometimes" as that confuses users and
tools alike – so even if removing code in use for (close to) 18 years
feels wrong, it is probably the right choice for consistency.
Closes: 818162
Report non-transient errors as errors, not as warnings2016-03-16T16:56:50ZJulian Andres Klodejak@debian.org2016-03-16T15:46:39Zurn:sha1:f695e76199a43b7f4d5816e20d18496b6448b833
This makes it easier to understand what really is an error
and what not.
Get accurate progress reporting in apt update again2016-03-16T16:52:40ZMichael Vogtmvo@ubuntu.com2016-03-15T13:50:37Zurn:sha1:fb193b1cd43f0e8c3b7e5f69f183b9abe7e83761
For the non-pdiff case, we have can have accurate progress
reporting because after fetching the {,In}Release files we know
how many IndexFiles will be fetched and what size they have.
Therefore init the filesize early (in pkgAcqIndex::Init) and
ensure that in Acquire::Pulse() looks at already downloaded
bits when calculating the progress in Acquire::Pulse.
Also improve debug output of Debug::acquire::progress