apt, branch 1.2.9

Release 1.2.9

2016-03-27T00:30:31Z

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

drop confusing comma from no strong hash message

2016-03-25T08:31:42Z

Release 1.2.8

2016-03-24T18:31:51Z

Update symbols file

2016-03-24T14:16:00Z

Set hidden visibility for StringView

2016-03-24T14:16:00Z

This avoids templates using StringView to be exported, such as std::vector::emplace_back(). Gbp-Dch: ignore

Japanese manpage translation update

2016-03-24T09:24:43Z

Closes: 818950

handle gpgv's weak-digests ERRSIG

2016-03-22T00:58:45Z

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:17Z

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

refactor loading of previous release file

2016-03-19T08:48:44Z

There is really no need to have the same code three times. Git-Dch: Ignore