apt/test/integration, branch 1.2.11

ensure outdated files are dropped without lists-cleanup

2016-04-14T20:21:53Z

Tested via (newly) empty index files, but effects also files dropped from the repository or an otherwise changed repository config.

silently skip acquire of empty index files

2016-04-14T19:56:01Z

There is just no point in taking the time to acquire empty files – especially as it will be tiny non-empty compressed files usually.

allow uncompressed files to be empty in store again

2016-04-14T14:55:35Z

With the previous fix for file applied we can again hit repositories which contain uncompressed empty files, which since the introduction of the central store: method wasn't accounted for anymore as we forbid empty compressed files.

fix Alt-Filename handling of file method

2016-04-14T14:15:39Z

A silly of-by-one error in the stripping of the extension to check for the uncompressed filename broken in an attempt to support all compressions in commit a09f6eb8fc67cd2d836019f448f18580396185e5. Fixing this highlights also mistakes in the handling of the Alt-Filename in libapt which would cause apt to remove the file from the repository (if root has the needed rights – aka the disk isn't readonly or similar)

stop handling items in doomed transactions

2016-04-07T11:48:31Z

With the previous commit we track the state of transactions, so we can now use our knowledge to avoid processing data for a transaction which was already closed (via an abort in this case). This is needed as multiple independent processes are interacting in the process, so there isn't a simple immediate full-engine stop and it would also be bad to teach each and every item how to check if its manager has failed subordinate and what to do in that case. In the pdiff case, which deals (potentially) with many items during its lifetime e.g. a hashsum mismatch in another file can abort the transaction the file we try to patch via pdiff belongs to. This causes some of the items (which are already done) to be aborted with it, but items still in the process of acquisition continue in the processing and will later try to use all the items together failing in strange ways as cleanup already happened. The chosen solution is to dry up the communication channels instead by ignoring new requests for data acquisition, canceling requests which are not assigned to a queue and not calling Done/Failed on items anymore. This means that e.g. already started or pending (e.g. pipelined) downloads aren't stopped and continue as normal for now, but they remain in partial/ and aren't processed further so the next update command will pick them up and put them to good use while the current process fails updating (for this transaction group) in an orderly fashion. Closes: 817240 Thanks: Barr Detwix & Vincent Lefevre for log files

Allow lowering trust level of a hash via config

2016-03-28T12:59:33Z

Introduces APT::Hashes:: with entries Untrusted and Weak which can be set to true to cause the hash to be treated as untrusted and/or weak.

test-apt-update-reporting: Make more use of framework

2016-03-27T13:14:32Z

Use msgtest and testsuccess with a function instead of failing with a simple exit 1. This looks nicer. Gbp-Dch: ignore

test-acquire-same-file-multiple-times: Delete files before retrying

2016-03-27T10:37:09Z

This gets rid of byte-range requests and 416 responses. Gbp-Dch: ignore

test-apt-download-progress: Use a larger file for testing

2016-03-27T10:31:24Z

This should make the test less flaky, as with a small file, we might have already received all the data before trying to apply rate limits which is a constant source of failure on the i386 Ubuntu autopkgtest.

Do not mark packages for keep that we want to remove

2016-03-27T00:09:14Z

If the package is marked for removal, keep it marked for removal and do not mark it for keep. If we mark it for keep, we some how later get to a different stage where it is marked for unpack instead of removal. In the example in the bug report, we would get a: SmartUnPack maas-region-controller-min:amd64 (replace version 2.0.0~alpha3+bzr4810-0ubuntu1 with Segmentation fault maas-region-controller-min:amd64 was marked for removal, but we changed it to keep and somehow it thinks that this is to be replaced now instead of removed (probably because the InstallVer != CandidateVer [with InstallVer = 0]). This fixes a regression introduced in release 1.2.7, commit: 0390edd5452b081f8efcf412f96d535a1d959457 Reported-by: LaMont Jones on IRC LP: #1562402