apt/test, branch 3.1.8

Add history undo, redo, and rollback features

2025-10-02T10:49:58Z

test-history: Adjust for as-installed testing

2025-09-30T11:01:28Z

When testing as installed, we inadvertently do not replace the command-line with dummy in the "apt history-list" command.

history: Handle transactions without any changes

2025-09-26T16:49:53Z

For some reason I have them in my log file.

test-history: Do not fully remove the command line

2025-09-26T16:48:40Z

This will particularly be useful in the next commit; just strip the path form the commandline.

History Command and Parsing

2025-09-26T16:18:42Z

Support kernel images with + in uname in kernel autoremove test

2025-09-02T18:50:04Z

autopkgtest run on stable can have an uname like "6.12.41+deb13-amd64". The +deb13 being relatively new in the package name. The code doing the autoremoval has no problem with it and its a legal package name, but the test that wants to check if the right regexes are generated does not escape the + correctly (aka at all) so it isn't finding the regex it is looking for failing the test.

Show command in test failure messages if default is overridden

2025-09-02T18:50:04Z

Tests usually print the command they run, but it can be overridden with a chosen message to make clearer what is actually tested. To debug failures it can be useful to know the command run through especially if its a partly generated command depending on the test environment (like in the kernel autoremove test).

solver3: Allow any downloadable version to mark a package as not obsolete

2025-08-26T11:41:35Z

Lots of people have pinned an older version that is no longer installable, or more common yesterday, we saw a lot of people who seemingly manually installed a newer version of a deb than in the repositories, causing the package to be considered obsolete, which does not make much sense. Oops: 4c39d922-410f-11f0-bbf9-fa163ec44ecd Oops: a64054f6-4140-11f0-bbfd-fa163ec44ecd Oops: a32196c1-661d-11f0-a97c-fa163ec8ca8c

solver3: Sort dependency targets against current alternative

2025-08-26T11:41:35Z

Instead of inadvertently sorting dependency targets against the first alternative in an or group, sort them against the current alternative as we should. Otherwise we ended up sorting gnome-shell | notification-daemon With Package: notification-daemon Package: awesome Provides: notification-daemon into gnome-shell | awesome | notification-daemon <-we sorted this part wrongly-> This fixes a minor difference in test-release-candidate-switching in one case, but not the other where the difference was actually caused by the loss of install argument ordering information in the new solver, so just flip the arguments so both solvers produce the same outcome.

Fix stuck acquire queues on partial server errors

2025-06-24T16:47:18Z

When a server responds with two InRelease files, but one is good, and the other indicates a temporary error, we queued the other indices from the good repository for downloading and then queued the retry. The resulting queue ended up with items having fetchAfter=0 before the item with fetchAfter=, causing the Run() loop to not detect a stuck queue. Change the order of the queue such that the highest retry-after items comes first; this ensures that we always see stuck queues. This of course changes the behavior of retries in that if one file fails temporarily we block the entire server. This does seem more beneficial in the common case - if one file fails, probably all of them fail, and there's no point bombarding the server with requests for indices from good repositories until all have failed. The actual root cause is more that the remaining items are Enqueued like this: 1. Enqueue jammy/InRelease (delayed) 2. Enqueue jammy-updates/main all Packages The resulting queue ended up being: jammy-updates/main all Packages jammy/InRelease (delayed) But Enqueue() only calls Cycle() when there are no items in the queue already - after all, any item that is already running will call Cycle() eventually. Or so was the case until we added the retry-after handling. It's unclear why we don't Cycle() all the time when enqueuing a new item, given that our pipeline might not be filled yet, and we could send the request to the server while waiting for data on a running item. Trying to always Cycle() however led to regressions that still need investigating. Given that, this solution certainly is the more easy to reason about one. LP: #2003851