apt, branch 1.2.6

Release 1.2.6

2016-03-07T18:51:34Z

apt-pkg/algorithms.cc: Avoid stack buffer overflow in KillList

2016-03-07T00:41:39Z

Dynamically allocate KillList in order to avoid an overflow when more than 100 elements would be written to it. This happened while playing around with the status file from Bug#701069 on a modern system.

Fix several typos

2016-03-06T23:14:48Z

This effectively merges branch 'typofixes-vlajos-20150807' of github.com:vlajos/apt with the following commit: commit 13cacb3e2e2352ba701e769fc889e3344fabbf7e Author: Veres Lajos Date: Sun Aug 9 00:12:53 2015 +0100 typofix - https://github.com/vlajos/misspell_fixer It has been rebased for a better commit message.

Release 1.2.5

2016-03-06T18:48:39Z

debian/control: Set Standards-Version to 3.9.7

2016-03-06T14:27:10Z

We do not follow the recommendation with regards to placement of documentation in apt-doc, as we install in apt-doc, but it's only a recommendation and I don't want think we should move them.

get group again after potential remap in Source: parse

2016-03-06T14:00:33Z

Mysteriously segfaults only on i386 for me, but at least one reporter had the same behavior and it makes sense that this is the problem as the parsing of Source: was fixed in 1.2.2 – before the not remapped group was not used. We don't use our usual Dynamic<> trick here as we don't have it in the parser. Its a bit of a layer violation to do this parsing here, but its how it is always was… Until next time with this lovely kind of problem. Closes: 812251 Thanks: Francesco Poli and Marc Haber for testdata.

Prevent double remapping of iterators and string views

2016-03-06T13:57:41Z

If an iterator or a stringview has multiple dynamic objects registered with it, it may be remapped twice. Prevent that by noting which iterators/views we have seen and not remapping one if we have already seen it. We most likely do not have any instance of multiple dynamics on a single object, but let's play safe - the overhead is not high.

do not move not-failed pdiff-patches into CWD on failure

2016-03-06T11:57:38Z

If a single pdiff fails, we have to fail the entire patching endeavour and fall back to getting the complete file instead. That is easy in serverside merged pdiffs as we get them one by one. For clientside we get them all at once through, which means that a failure in one has to stop the entire pipeline, which works as expected (as proven by the bugreporters as they don't even notice it happening). The problem is just that the first failing pdiff will do the cleanup, so another pdiff which happens to be successfully acquired after we processed the failure doesn't find the file it is supposed to use as a basename anymore, so the patch is renamed to what should be the unique extension and moved into the current working directory. Processing is then stopped as the patch realizes that it isn't the last one which completed downloading. On the plus side this means this is neither us using a bad temporary location nor a security problem. It "just" overrides unconditionally files in your current working directory (if you happen to have them named like a pdiff patch – a bit unlikely perhaps) and so drops files there which are never used again. I guess this was introduced in 4e3c5633b1e74b4f58b95f339cfbbf4cbf21ab3e for real as I made the need for the existence of the base file rather explicit, but the potential lingers in the code for far longer. Closes: #816837

Fix lzma write support to handle "try again" case

2016-03-06T09:22:45Z

The liblzma-based write code needs the same tweaks that the read code already has to cope with the situation where lzma_code returns zero the first time through because avail_out is zero, but will do more work if called again. This ports the read tweaks to the write code as closely as possible (including matching comments etc.). Closes: #751688

add test for apt-key 0xKEY and use parameter expansion

2016-03-06T09:16:59Z

Fixed in f7bd44bae0d7cb7f9838490b5eece075da83899e already, but the commit misses the Closes tag and while we are at it we can add a simple regression test and micro-optimize it a bit. Thanks: James McCoy for the suggestion. Closes: 816691