<feed xmlns='http://www.w3.org/2005/Atom'>
<title>apt/test, branch 2.5.2</title>
<subtitle>Debians commandline package manager</subtitle>
<id>https://git.kalnischkies.de/apt/atom?h=2.5.2</id>
<link rel='self' href='https://git.kalnischkies.de/apt/atom?h=2.5.2'/>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/'/>
<updated>2022-07-24T13:44:13Z</updated>
<entry>
<title>Add flag to disable upgrade by source and test case</title>
<updated>2022-07-24T13:44:13Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-07-24T13:44:13Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=518746f7e03115eb7bdf894d23e74ae115c8717b'/>
<id>urn:sha1:518746f7e03115eb7bdf894d23e74ae115c8717b</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Upgrade all binaries in a source package</title>
<updated>2022-07-24T13:27:18Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-07-08T11:34:22Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=119a8d0ed19a4e946591b9aef7d662e14ca7ece5'/>
<id>urn:sha1:119a8d0ed19a4e946591b9aef7d662e14ca7ece5</id>
<content type='text'>
Schedule all other binaries in the source package for upgrade if
the candidate version belongs to the same source version as the
package we are upgrading.

This will significantly reduce the risk of partial upgrades and
should make life a lot easier.
</content>
</entry>
<entry>
<title>Add test cases</title>
<updated>2022-07-11T16:06:59Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-07-11T14:36:59Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=07fe16bcc62fc84571ff90e8ec6d033226ce431a'/>
<id>urn:sha1:07fe16bcc62fc84571ff90e8ec6d033226ce431a</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Mark broken reverse depends for upgrade</title>
<updated>2022-07-11T14:37:33Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-07-08T15:46:05Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e077370ffcb3669a50a600e80356c2002e6b176d'/>
<id>urn:sha1:e077370ffcb3669a50a600e80356c2002e6b176d</id>
<content type='text'>
Currently the solver handles cases where a Breaks b (&lt;&lt; 1) and
if we install that a, upgrades b. However, where b Depends a (= 1),
b was removed again.

This addresses the problem by iterating over installed reverse
dependencies of upgrades and upgrading them so that both cases
work roughly similarly.

LP: #1974196
</content>
</entry>
<entry>
<title>test-phased-updates-upgrade: Tests with arguments</title>
<updated>2022-06-30T11:21:19Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-06-30T11:20:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8416bcb58cba0f8b5e8e8d26b71ae838f228111d'/>
<id>urn:sha1:8416bcb58cba0f8b5e8e8d26b71ae838f228111d</id>
<content type='text'>
Pass some package names to upgrade to see that that works

Gbp-Dch: ignore
</content>
</entry>
<entry>
<title>policy: Do not override negative pins with 1 due to phasing</title>
<updated>2022-06-28T12:54:42Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-06-28T12:53:14Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=20739359fa936c0851a4c0f37667526d98c22761'/>
<id>urn:sha1:20739359fa936c0851a4c0f37667526d98c22761</id>
<content type='text'>
If a package is already pinned to a negative value, we should not
override this with a positive 1. This causes packages to be installable
that were pinned to -1, which is not intended.

For this, implement phasing as a ceiling of 1 for the pin instead
of a fixed 1 value. An alternative would have been to fix it to
NEVER_PIN, but that would mean entirely NEW packages would not be
installable while phasing which is not the intention either.

LP: #1978125
</content>
</entry>
<entry>
<title>(Temporarily) Rewrite phased updates using a keep-back approach</title>
<updated>2022-06-28T12:25:18Z</updated>
<author>
<name>Julian Andres Klode</name>
<email>julian.klode@canonical.com</email>
</author>
<published>2022-06-24T14:09:24Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=db131677bee45c86031d37d7b451e6ece692efb2'/>
<id>urn:sha1:db131677bee45c86031d37d7b451e6ece692efb2</id>
<content type='text'>
This is a lot closer to the original implementation in update-manager,
but still has a couple of differences that might cause bugs:

- When checking whether a version is a security update, we only
  check versions in between and not any later version. This happens
  mostly because we do not know the suite, so we just check if there
  is any version between the installed version and our target that
  is a security update

- We only keep already installed packages, as we run before the
  resolver. update-manager first runs the resolver, and then marks
  for keep all packages that were upgraded or newly installed that
  are phasing (afaict).

This approach has a significant caveat that if you have version 1
installed from a release pocket, version 2 is in security, and version
3 is phasing in updates, that it installs version 3 rather than 2
from security as the policy based implementation does.

It also means that apt install does not respect phasing and would
always install version 3 in such a scenario.

LP: #1979244
</content>
</entry>
<entry>
<title>Include our config.h in all C++ files to avoid ODR violations</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-22T15:05:36Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=320245536a7ad21606286d9dcf54acf3bdf096c6'/>
<id>urn:sha1:320245536a7ad21606286d9dcf54acf3bdf096c6</id>
<content type='text'>
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
</content>
</entry>
<entry>
<title>Ignore stty failures in testcases</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-21T10:51:20Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=e5aa5c04ecbd3cdab611794cebf9eb3aa8cbddd4'/>
<id>urn:sha1:e5aa5c04ecbd3cdab611794cebf9eb3aa8cbddd4</id>
<content type='text'>
We use 'stty sane' to combat against stepped output and co caused by
(especially) failed tests, but it does so many things that it
occasionally fails to reset some bits in the parallel interaction we
have with it which fails the tests without a real problem in apt…

Ideally we would be better at stitching the output together, but for the
time being lets ignore these failures instead to stabilize the tests.
</content>
</entry>
<entry>
<title>Link interactive helpers against system libapt for autopkgtest</title>
<updated>2022-05-07T08:45:44Z</updated>
<author>
<name>David Kalnischkies</name>
<email>david@kalnischkies.de</email>
</author>
<published>2022-04-20T23:45:45Z</published>
<link rel='alternate' type='text/html' href='https://git.kalnischkies.de/apt/commit/?id=8d8b45a96ceceb015f7836cf25b99279c2f377b9'/>
<id>urn:sha1:8d8b45a96ceceb015f7836cf25b99279c2f377b9</id>
<content type='text'>
Building the library just so we can build the helpers against it is not
only wasteful but as we are supposed to test the system we can use that
as an additional simple smoke test before the real testing starts.
</content>
</entry>
</feed>
