<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test, branch 2.3.0</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.3.0</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.3.0'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2021-03-07T01:55:07Z</updated>
<entry>
<title>Ensure all index files sent custom tags to the methods</title>
<updated>2021-03-07T01:55:07Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-03-06T15:11:34Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=2a81f98b124d8fe551b160df55db1d3bf79a77c1'/>
<id>urn:sha1:2a81f98b124d8fe551b160df55db1d3bf79a77c1</id>
<content type='text'>
The mirror method can distribute requests for files based on various
metadata bits, but some – the main index files – weren't actually
passing those on to the methods as advertised in the manpage.

This is hidden both by mirror usually falling back to other sources
which will eventually hit the right one and that if the repository does
not support by-hash apt will automatically stick to the mirror which was
used for the Release file.
</content>
</entry>
<entry>
<title>Start pdiff patching from the last possible starting point</title>
<updated>2021-03-07T01:55:07Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-03-06T23:47:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=59933938f51105066161a6eb88253006826336a2'/>
<id>urn:sha1:59933938f51105066161a6eb88253006826336a2</id>
<content type='text'>
Especially in small sections of an archive it can happen that an index
returns to a previous state (e.g. if a package was first added and then
removed with no other changes happening in between). The result is that
we have multiple patches which start from the same hash which if we
perform clientside merging is no problem although not ideal as we
perform needless work.

For serverside merging it would not matter, but due to rred previously
refusing to merge zero-size patches but dak ignoring failure letting it
carry these size-zero patches until they naturally expire we run into a
problem as these broken patches won't do and force us to fall back to
downloading the entire index. By always starting from the last patch
instead of the first with the starter hash we can avoid this problem
and behave optimally in clientside merge cases, too.
</content>
</entry>
<entry>
<title>Rename pdiff merge patches only after they are all downloaded</title>
<updated>2021-03-07T01:55:07Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-03-06T18:55:09Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=246f66561e23911b9615bd337b3b6f6f25b6cd31'/>
<id>urn:sha1:246f66561e23911b9615bd337b3b6f6f25b6cd31</id>
<content type='text'>
The rred method expects the patches to have a certain name, which we
have to rename the file to before calling the method, but by delaying
the rename we ensure that if the download of one of them fails and a
successful fallback occurs they are all properly cleaned up as no longer
useful while in the error case the next apt run can potentially pick
them up as already downloaded.

Our test-pdiff-usage test was encountering this every other run, but did
not fail as the check for unaccounted files in partial/ was wrapped
in a subshell so that the failure produced failing output, but did not
change the exit code.
</content>
</entry>
<entry>
<title>Allow merging with empty pdiff patches</title>
<updated>2021-03-06T14:02:26Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-03-06T14:02:26Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=9bd27033c4786fa89cebc9d090ad2c6e8f47b598'/>
<id>urn:sha1:9bd27033c4786fa89cebc9d090ad2c6e8f47b598</id>
<content type='text'>
There isn't a lot of sense in working on empty patches as they change
nothing (quite literally), but they can be the result of merging
multiple patches and so to not require our users to specifically detect
and remove them, we can be nice and just ignore them instead of erroring
out.
</content>
</entry>
<entry>
<title>regression fix: do require force-loopbreak for Conflicts</title>
<updated>2021-03-01T20:43:54Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-03-01T20:43:03Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0d51cf142884801c903df0cddaec5545f0174553'/>
<id>urn:sha1:0d51cf142884801c903df0cddaec5545f0174553</id>
<content type='text'>
Conflicts do require removing the package temporarily, so they really
should not be used.

We need to improve that eventually such that we can deconfigure packages
when we have to remove their dependencies due to conflicts.
</content>
</entry>
<entry>
<title>Do not require force-loopbreak on Protected packages</title>
<updated>2021-02-23T18:10:29Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-02-23T17:23:30Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=f8ff3afcd42d8b2e6506bc6f44a894149bf87442'/>
<id>urn:sha1:f8ff3afcd42d8b2e6506bc6f44a894149bf87442</id>
<content type='text'>
dpkg will be changed in 1.20.8 to not require --force-remove for
deconfiguration anymore, but we want to decouple our changes from the
dpkg ones, so let's always pass --force-remove-protected when installing
packages such that we can deconfigure protected packages.

Closes: #983014
</content>
</entry>
<entry>
<title>Adjust loops to use size_t instead of int</title>
<updated>2021-02-09T22:49:31Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-02-09T22:49:31Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=ea114447ee44908c75f4ddc19a0521260832668d'/>
<id>urn:sha1:ea114447ee44908c75f4ddc19a0521260832668d</id>
<content type='text'>
Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>Fix test suite regression from StrToNum fixes</title>
<updated>2021-02-09T22:33:47Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-02-09T22:29:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=6284c8221da94ab6b4262795e6a7990fc3655848'/>
<id>urn:sha1:6284c8221da94ab6b4262795e6a7990fc3655848</id>
<content type='text'>
We ignored the failure from strtoul() that those test cases had values
out of range, hence they passed before, but now failed on 32-bit
platforms because we use strtoull() and do the limit check ourselves.

Move the tarball generator for test-github-111-invalid-armember to the
createdeb helper, and fix the helper to set all the numbers for like uid
and stuff to 0 instead of the maximum value the fields support (all 7s).

Regression-Of: e0743a85c5f5f2f83d91c305450e8ba192194cd8
</content>
</entry>
<entry>
<title>Prevent temporary directory from triggering failure grepping</title>
<updated>2021-02-04T10:00:00Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-02-04T08:38:01Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=131d0e3a261076da715102cb79275988cac810d1'/>
<id>urn:sha1:131d0e3a261076da715102cb79275988cac810d1</id>
<content type='text'>
The grep for case-insensitive GPG finds also e.g. "/tmp/tmp.Kc5kKgPg0D"
which is not the intention, so we simply eliminate the variation of the
/tmp directory here from the output to prevent these false positives.

Gbp-Dch: Ignore
</content>
</entry>
<entry>
<title>Avoid overstepping bounds in config file parsing</title>
<updated>2021-02-03T16:43:13Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-02-03T16:40:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=c4da2ff42da55ffc38c77a9170dc151216d75962'/>
<id>urn:sha1:c4da2ff42da55ffc38c77a9170dc151216d75962</id>
<content type='text'>
Our configuration files are not security relevant, but having a parser
which avoids crashing on them even if they are seriously messed up is
not a bad idea anyway. It is also a good opportunity to brush up the
code a bit avoiding a few small string copies with our string_view.
</content>
</entry>
</feed>
