apt, branch 1.7.0_rc1

Release 1.7.0~rc1 to unstable

2018-09-18T14:16:06Z

Merge branch 'pu/keep-pipelining-after-close' into 'master'

2018-09-18T14:10:03Z

http: Stop pipeline after close only if it was not filled before See merge request apt-team/apt!25

http: Stop pipeline after close only if it was not filled before

2018-09-18T14:07:24Z

It is perfectly valid behavior for a server to respond with Connection: close eventually, even when pipelining. Turning off pipelining due to that is wrong. For example, some Ubuntu mirrors close the connection after 101 requests. If I have more packages to install, only the first 101 would benefit from pipelining. This commit introduces a new check to only turn of pipelining for future connections if the pipeline for this connection did not have 3 successful fetches before, that should work quite well to detect broken server/proxy combinations like in bug 832113.

Merge branch 'bugfix/statusfd' into 'master'

2018-09-18T12:05:20Z

Process all of --status-fd and don't expect duplicate status msg See merge request apt-team/apt!26

Show all architectures in 'apt list' output

2018-09-15T15:45:16Z

The uniqueness in std::set containers is ensured by the ordering operator we provide, but it was not considering that different versions can have the same description like the different architectures for a version of a package. Closes: #908218

Reorder progress report messages

2018-09-11T11:08:58Z

We are seeing 'processing' messages from dpkg first, so it makes sense to translate them to "Preparing" messages instead of using "Installing" and co to override these shortly after with the "Preparing" messages. The difference isn't all to visible as later messages tend to linger far longer in the display than the ealier ones, but at least in a listing it seems more logical.

Don't expect duplicated dpkg status-fd messages

2018-09-11T11:08:58Z

The progress reporting relies on parsing the status reports of dpkg which used to repeat being in the same state multiple times in the same run, but by fixing #365921 it will stop doing so. The problem is in theory just with 'config-files' in case we do purge as this (can) do remove + purge in one step, but we remove this also for the unpack + configure combination althrough we handle these currently in two independent dpkg calls.

Process status-fd completely before finishing dpkg call

2018-09-11T11:08:58Z

Exiting the processing loop as soon as the dpkg process finishes might leave status-fd lines unprocessed which wasn't much of a problem in the past as the progress would just be slightly off, but now that we us the information also for skipping already done tasks and generate warnings if we didn't see all expected messages we should make sure we seem them all. We still need to exit "early" if dpkg exited unsuccessfully/crashed through as the (remaining) status lines we get could be incomplete.

Unset more environment variables in test framework

2018-09-11T10:59:01Z

It is an uphill battle to "reset" the environment to a clean state without making it needlessly hard to use 'good' environment variables, so we just try a little harder here without really trying for completeness. Gbp-Dch: Ignore

Don't use gpg directly in apt-key test

2018-09-10T19:57:51Z

Reported-By: Guillem Jover Gbp-Dch: Ignore