<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test/integration, branch 2.3.1</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.3.1</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.3.1'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2021-04-13T14:00:41Z</updated>
<entry>
<title>Error on packages without a Size field (option Acquire::AllowUnsizedPackages)</title>
<updated>2021-04-13T14:00:41Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-04-09T16:16:10Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=1412cf51403286e9c040f9f86fd4d8306e62aff2'/>
<id>urn:sha1:1412cf51403286e9c040f9f86fd4d8306e62aff2</id>
<content type='text'>
Repositories without Size information for packages are not
proper and need fixing. This ensures people see an error in
CI, and get notifications and hence the ability to fix it.

It can be turned off by setting Acquire::AllowUnsizedPackages
to true.
</content>
</entry>
<entry>
<title>Fix downloads of unsized files that are largest in pipeline</title>
<updated>2021-04-13T14:00:41Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2021-04-09T16:11:02Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=27a4fb3a9ac67a13ed516c75feefdc1fd426520a'/>
<id>urn:sha1:27a4fb3a9ac67a13ed516c75feefdc1fd426520a</id>
<content type='text'>
The maximum request size is accidentally set to any sized file,
so if an unsized file is present, and it turns out to be larger
than the maximum size we set, we'd error out when checking if
its size is smaller than the maximum request size.

LP: #1921626
</content>
</entry>
<entry>
<title>Harden test for no new acquires after transaction abort</title>
<updated>2021-03-11T13:05:41Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2021-03-11T12:38:53Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=0d25ce3d466ecddea02d171981f011f7dbf95e08'/>
<id>urn:sha1:0d25ce3d466ecddea02d171981f011f7dbf95e08</id>
<content type='text'>
If a transaction is doomed we want to gracefully shutdown our zoo of
worker processes. As explained in the referenced commit we do this by
stopping the main process from handing out new work and ignoring the
replies it gets from the workers, so that they eventually run out of
work.

We tested this previously by checking if a rred worker was given work
items at all, but depending on how lucky the stars of the machine
working on this are the worker would have already gotten work before the
transaction was aborted – so we tried this 25 times a row (f35601e5d2).
No machine can be this lucky, right?

Turns out the autopkgtest armhf machine is very lucky.

I feel a bit sorry for feeding grep such a long "line" to work with, but
it seems to work out. Porterbox amdahl (who is considerably less lucky;
had to turn down to 1 try to get it to fail sometimes) is now happily
running the test in an endless loop.

Of course, I could have broken the test now, but its still a rather
generic grep (in some ways more generic even) and the main part of the
testcase – the update process finishes and fails – is untouched.

References: 38f8704e419ed93f433129e20df5611df6652620
Closes: #984966
</content>
</entry>
<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>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>
</feed>
