Hi,
for a while I've been having the problem with `apt update` that it
pretends to complete successfully, but it didn't actually pull updated
index data. I run it like this:
$ sudo apt-get update
[sudo] Passwort für sven:
OK:1 https://deb.debian.org/debian testing InRelease
OK:2 https://deb.debian.org/debian unstable InRelease
OK:3 https://deb.debian.org/debian experimental InRelease
OK:4 https://deb.debian.org/debian-debug testing-debug InRelease
OK:5 https://deb.debian.org/debian-debug unstable-debug InRelease
OK:6 https://deb.debian.org/debian-debug experimental-debug InRelease
Paketlisten werden gelesen… Fertig
Now, looking at the Packages file from the mirror, it looks like
testing has qemu-system-misc 1:9.0.2+ds-2+b1. But my just-updated
metadata doesn't seem to agree:
$ apt-cache policy qemu-system-misc
qemu-system-misc:
Installiert: 1:8.2.4+ds-1
Installationskandidat: 1:8.2.4+ds-1
Versionstabelle:
1:9.0.2+ds-1 102
102 https://deb.debian.org/debian unstable/main amd64 Packages
*** 1:8.2.4+ds-1 990
990 https://deb.debian.org/debian testing/main amd64 Packages
100 /var/lib/dpkg/status
$ grep -A2 'Package: qemu-system-misc'
/var/lib/apt/lists/deb.debian.org_debian-debug_dists_testing-
debug_main_binary-amd64_Packages
Package: qemu-system-misc-dbgsym
Source: qemu
Version: 1:8.2.4+ds-1
The hash in the corresponding InRelease also doesn't agree with the
cached file:
$ grep 'main/binary-amd64/Packages$'
deb.debian.org_debian_dists_testing_InRelease
85310e27a3e9c360968b172ca0877f89 53381870 main/binary-amd64/Packages
7951679347c89686f9ea401acc829c000c44a6c2e857d829357a68b8c8427c5e
53381870 main/binary-amd64/Packages
$ md5sum deb.debian.org_debian_dists_testing_main_binary-amd64_Packages
7e4eb0b9e3c72c4162beef26eb88fc08
deb.debian.org_debian_dists_testing_main_binary-amd64_Packages
Deleting the outdated file (or all contents of /var/lib/apt/lists/)
causes an up-to-date version of the deleted file(s) to be downloaded.
But once that file is cached again, it will not be updated again.
Every few days, I apparently do get up-to-date index files, as
witnessed by having a huge bunch of updates available from time to
time. Unfortunately I have so far never been able to observe this
directly when it happens, as it usually happens during automatic
updates by GNOME.
This bug manifests on this one machine I'm reporting from. So far I
have not been able to observe the same bug on other similar machines.
This suggests to me that I may have messed up some configuration
somewhere. Unfortunately I've been having this problem for a while and
I can't remember when it started to happen and I don't have any idea
what might be causing it on my machine.
Regards
Sven
Control: severity -1 important updated [...] I've also seen this occasionally. I would consider this at least 'important' as it can cause security updates to silently not be applied. It happened again today and I remembered to take a snapshot of the VM before working around it. So I can provide whatever information is needed from that snapshot. Ben.
Seeing this too on my machine. Changing the domains in sources.list allows me to fetch indexes again so I'm daily switching between deb.debian.org and ftp.fr.debian.org.
severity 1078608 serious thanks On Tue, 13 Aug 2024 19:57:58 +0200 Sven Bartscher <kritzefitz@debian.org> wrote: > Package: apt > Version: 2.9.7 > Severity: normal > > Hi, > > for a while I've been having the problem with `apt update` that it > pretends to complete successfully, but it didn't actually pull updated > index data. I run it like this: > > $ sudo apt-get update > [sudo] Passwort für sven: > OK:1 https://deb.debian.org/debian testing InRelease > OK:2 https://deb.debian.org/debian unstable InRelease > OK:3 https://deb.debian.org/debian experimental InRelease > OK:4 https://deb.debian.org/debian-debug testing-debug InRelease > OK:5 https://deb.debian.org/debian-debug unstable-debug InRelease > OK:6 https://deb.debian.org/debian-debug experimental-debug InRelease > Paketlisten werden gelesen… Fertig I do have the same issue I enabled debugging in apt (Debug::Acquire::http=true) and I see the following: In /var/lib/apt/lists I see So it seems that the InRelease file was downloaded, but not the rest If I delete the InRelease file, the other files are being downloaded
Am Wed, Apr 16, 2025 at 11:23:03AM +0200, schrieb Laurent Bigonville: You have what issue? Some people have that "same issue" by incorrectly copying/restoring the lists/ directory. Is that your issue? On the surface, and with the output you present/quoted this is perfectly normal and expected. apt will ask for a InRelease file first and if that didn't change there is no point in asking for the other files: In the best case the server will just say the files didn't change. Alternatively, the server replies with newer/older files we have no checksums for and would need to refuse anyhow. […] […] So this contrib is listed in https://snapshot.debian.org/file/6c3f5892d4c6363f4b4f6ed076fcc8fd7cd120cd/Release which is dated Tue, 15 Apr 2025 02:19:53 UTC. Some of the other index files are dated later than that Release file through, so probably more like this one: https://snapshot.debian.org/file/c95522b0bfabf1e1f2277d36f12b3861ae9c1b0c/Release which is dated Tue, 15 Apr 2025 14:13:09 UTC and also lists that file unchanged (which btw also causes apt to not download that index "again" if you update from the first to the second Release file). The Release file you currently have could be https://snapshot.debian.org/file/d47c8fc56da7f58c6ab18309c26b8337b76bfc4c/Release dated Wed, 16 Apr 2025 08:17:02 UTC, that has a different size for that file – the moment that Release file got downloaded apt should have also downloaded the new version of that contrib file and "installed" them together. I picked that file at semi-random as contrib changes less often than main stuff & I can look for the size as your config happens to have that file being uncompressed. You also have Contents files, which are useless in this lookup as they are lz4 compressed – good for usage, but that compression only exists in storage, not in the Release file (which also explains why apt can't just "recover" from this problem by checking hashsums of the files it has in storage as in general it doesn't have the hashes and just has to assume that what it has in storage is what is listed in the old Release file it has in storage, too). The interesting thing to discover now is what happened in these 24 hours on your system that lists/ got a new Release file (or, well InRelease), but not new indexes… unsurprisingly that shouldn't happen, but so far nobody has provided any leads as people notice only after the fact and at that point any debugging is pointless. The only scenario I know of is disabling APT::Get::List-Cleanup and running apt with a (slightly) different sources.list – like without contrib. I am not quite sure how we could solve that scenario given in some way its what the user requested; but not what they wanted. I know some front ends might use that option. I suppose some users could produce with interesting read permissions on configuration combined with those front ends such a case by "accident". In any case, I doubt that is what is happening here for "most" people with the "same" issue, so I haven't thought about that too much yet. Now, given you are in that situation, apt will at some point "recover" from it, given that eventually InRelease will be updated and the files it contains will eventually change, too. You 'only' forced that by removing the InRelease file. You also could have removed the index… (apt would have noticed that the file isn't there and downloads it even if you got a hit on the Release given we have to deal with config changes, like you adding another architecture since the last update but before the next mirror change). Not that it makes any practical difference in the apt team if you tag it wishlist or critical, but I am curious: Which section in the Debian policy is apt violating here? Or have I just missed you joining the apt team and/or Debian Release team? (See https://www.debian.org/Bugs/Developer#severities) Some maintainers can get really angry if you use the wrong severities, so ideally, next time, you should give a justification at least. Best regards David Kalnischkies
What is the Date field in the InRelease file?
Le 17/04/25 à 22:59, David Kalnischkies a écrit : The fact that the indexes are not updated when running "apt-get update" meaning that apt is not seeing the updates leaving my machine not up-to-date. I didn't manipulate the indexes by hand in any ways before to that. It's a laptop with a desktop environment and PackageKit is installed, not sure whether PK could impact this. Also the laptop has been probably restarted in between so that means that PK has restarted and probably tried to update the indexes. Serious severity is: In my opinion, having trouble to update a system makes apt "unsuitable for release". And marking it "serious" makes this visible to the release manager team. But if you, as a maintainer, believe that apt can be shipped in the next stable version of debian with that bug open, please tell me and I'll reduce the severity. I personally get "really angry" if I have packages (with potential security issues) not being timely updated, everybody has their quirk I guess...
Le 18/04/25 à 09:43, Julian Andres Klode a écrit : I didn't write it down, next time I'm facing the issue I'll write that down Kind regards, Laurent Bigonville
Am Fri, Apr 18, 2025 at 11:30:12AM +0200, schrieb Laurent Bigonville: always the possibility of the front end holding it wrong. And there is never an easy tell which config they are using. (At least I don't know…) Anecdotal evidence suggests its some front end as I don't use any and don't have that problem, while initial reporter here claim they have it only on one system – while all likely have apt installed, so a general problem would appear in general… of course, that is a rather weak approach especially as this is both usually a silent issue and a self-healing one, but its all we have so far… Or if you will: +moreinfo +unreproducible. If I tagged every bug serious I thought makes something unsuitable for release or that I want other people to look at… but as you quoted my own opinion is irrelevant for the label 'serious' by design and it shouldn't be misused as "summoning magic" either… Tag it 'grave' if that is your reasoning (and it makes you feel better), but as already said at least here it doesn't really matter as we have a 1000+ open bugs against apt at least someone believes is serious in their opinion. Does it change anything? Nope. All it really does is that testers upgrading from stable will be scared by apt-listbugs in a sense having probably more negative impact on the release than this bug seems to be able to. In exchange, no magic army of coders appears that fixes bugs nor does anyone provide any meaningful details based on severity. For all we know, as we know nothing, apt/oldstable has that problem, too, (assuming of course its an apt problem to begin with) making that even more ironic. But it makes you feel better and I don't really care, so its fine. I was indeed just giving you a hint for next time on another package to include a justification rather than treat it as "obviously so". Best regards David Kalnischkies
Le 18/04/25 à 11:31, Laurent Bigonville a écrit : -rw-r--r-- 1 root root 29 Jan 8 2023 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_dep11_icons-64x64.tar.gz -rw-r--r-- 1 root root 29 Jan 8 2023 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_dep11_icons-48x48.tar.gz -rw-r--r-- 1 root root 1983 Mar 24 08:04 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_Contents-amd64.lz4 -rw-r--r-- 1 root root 342240 Apr 6 19:59 ftp.be.debian.org_debian_dists_unstable_contrib_Contents-amd64.lz4 -rw-r--r-- 1 root root 1546853 Apr 6 19:59 ftp.be.debian.org_debian_dists_unstable_non-free_Contents-all.lz4 -rw-r--r-- 1 root root 137064 Apr 8 14:18 ftp.be.debian.org_debian_dists_unstable_contrib_dep11_icons-64x64.tar.gz -rw-r--r-- 1 root root 63450 Apr 8 14:18 ftp.be.debian.org_debian_dists_unstable_contrib_dep11_icons-48x48.tar.gz -rw-r--r-- 1 root root 697879 Apr 12 02:02 ftp.be.debian.org_debian_dists_unstable_non-free_i18n_Translation-en -rw-r--r-- 1 root root 230711 Apr 13 02:09 ftp.be.debian.org_debian_dists_unstable_contrib_i18n_Translation-en -rw-r--r-- 1 root root 865256 Apr 13 02:10 ftp.be.debian.org_debian_dists_unstable_contrib_Contents-all.lz4 -rw-r--r-- 1 root root 15272 Apr 14 20:07 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_i18n_Translation-en -rw-r--r-- 1 root root 47849 Apr 15 20:05 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_Contents-all.lz4 -rw-r--r-- 1 root root 32205 Apr 15 20:06 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_binary-amd64_Packages -rw-r--r-- 1 root root 37646 Apr 15 20:08 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_source_Sources -rw-r--r-- 1 root root 38800 Apr 16 02:18 ftp.be.debian.org_debian_dists_unstable_non-free-firmware_dep11_Components-amd64.yml.gz -rw-r--r-- 1 root root 195967 Apr 17 02:09 ftp.be.debian.org_debian_dists_unstable_non-free_Contents-amd64.lz4 -rw-r--r-- 1 root root 868401 Apr 17 02:09 ftp.be.debian.org_debian_dists_unstable_non-free_binary-amd64_Packages -rw-r--r-- 1 root root 441330 Apr 17 02:12 ftp.be.debian.org_debian_dists_unstable_non-free_source_Sources -rw-r--r-- 1 root root 5552 Apr 17 08:18 ftp.be.debian.org_debian_dists_unstable_non-free_dep11_Components-amd64.yml.gz -rw-r--r-- 1 root root 277623 Apr 17 20:10 ftp.be.debian.org_debian_dists_unstable_contrib_source_Sources -rw-r--r-- 1 root root 26547 Apr 17 20:19 ftp.be.debian.org_debian_dists_unstable_non-free_dep11_icons-64x64.tar.gz -rw-r--r-- 1 root root 29 Apr 17 20:19 ftp.be.debian.org_debian_dists_unstable_non-free_dep11_icons-48x48.tar.gz -rw-r--r-- 1 root root 36717653 Apr 19 20:07 ftp.be.debian.org_debian_dists_unstable_main_i18n_Translation-en -rw-r--r-- 1 root root 301767 Apr 19 20:07 ftp.be.debian.org_debian_dists_unstable_contrib_binary-amd64_Packages -rw-r--r-- 1 root root 46273 Apr 20 02:16 ftp.be.debian.org_debian_dists_unstable_contrib_dep11_Components-amd64.yml.gz -rw-r--r-- 1 root root 15795108 Apr 20 08:08 ftp.be.debian.org_debian_dists_unstable_main_i18n_Translation-fr -rw-r--r-- 1 root root 8048500 Apr 20 14:10 ftp.be.debian.org_debian_dists_unstable_main_dep11_Components-amd64.yml.gz -rw-r--r-- 1 root root 3758040 Apr 20 14:13 ftp.be.debian.org_debian_dists_unstable_main_dep11_icons-48x48.tar.gz -rw-r--r-- 1 root root 7712649 Apr 20 14:13 ftp.be.debian.org_debian_dists_unstable_main_dep11_icons-64x64.tar.gz -rw-r--r-- 1 root root 59783017 Apr 20 19:59 ftp.be.debian.org_debian_dists_unstable_main_binary-amd64_Packages -rw-r--r-- 1 root root 62244346 Apr 20 20:00 ftp.be.debian.org_debian_dists_unstable_main_source_Sources -rw-r--r-- 1 root root 24671131 Apr 20 20:01 ftp.be.debian.org_debian_dists_unstable_main_Contents-amd64.lz4 -rw-r--r-- 1 root root 71231252 Apr 20 20:02 ftp.be.debian.org_debian_dists_unstable_main_Contents-all.lz4 -rw-r--r-- 1 root root 205189 Apr 21 02:11 ftp.be.debian.org_debian_dists_unstable_InRelease root@eriador:/var/lib/apt/lists# grep -i Date ftp.be.debian.org_debian_dists_unstable_InRelease Date: Mon, 21 Apr 2025 02:10:25 UTC root@eriador:/var/lib/apt/lists# LC_ALL=C TZ=UTC stat ftp.be.debian.org_debian_dists_unstable_main_binary-amd64_Packages File: ftp.be.debian.org_debian_dists_unstable_main_binary-amd64_Packages Size: 59783017 Blocks: 116776 IO Block: 4096 regular file Device: 253,1 Inode: 415634 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-04-20 21:58:14.350155500 +0000 Modify: 2025-04-20 19:59:58.000000000 +0000 Change: 2025-04-20 21:58:13.054173328 +0000 Birth: 2025-04-20 21:58:07.838245598 +0000 root@eriador:/var/lib/apt/lists# LC_ALL=C TZ=UTC stat ftp.be.debian.org_debian_dists_unstable_InRelease File: ftp.be.debian.org_debian_dists_unstable_InRelease Size: 205189 Blocks: 408 IO Block: 4096 regular file Device: 253,1 Inode: 402857 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2025-04-21 07:57:35.970510196 +0000 Modify: 2025-04-21 02:11:50.000000000 +0000 Change: 2025-04-21 07:57:35.970463426 +0000 Birth: 2025-04-21 07:40:41.263998091 +0000
hours InRelease), far and installed, not probably tried is know…) it [...] I kept a VM snapshot from one time this happened (in August 2024). As I offered before, I can run any tests you like on it. Having read the information added by Laurent I did some more testing today: - If I boot this snapshot normally then the InRelease files, but not the Packages files, get updated to the current versions. After that 'apt update' unsurprisingly does nothing. The automatic update of those files was presumably done by PackageKit. - If I mask packagekit.service before booting (using a rescue shell), then none of the files are updated automatically. Running 'apt update' updates them all as expected. So it seems like this problem may be specific to PackageKit. Sven and Laurent, do your affected systems have PackageKit installed? Ben.
Hi, Am Sonntag, dem 27.04.2025 um 16:18 +0200 schrieb Ben Hutchings: My affected system has PackageKit installed, though PK was relatively recently installed on this machine. I actually only noticed this bug after PK had been installed, never before, which might be a hint that PK is actually the cause. Though I don't remember how much time passed between installing PK and me actually noticing the problem, so it's not really clear-cut evidence. More recently I noticed that my machine is no longer affected by this problem. I think the problem disappeared when I switched the suite value in my APT sources from “testing” to „trixie”. Regards Sven
On Sun, 27 Apr 2025 16:18:39 +0200 Ben Hutchings <ben@decadent.org.uk> wrote: > > So it seems like this problem may be specific to PackageKit. > > Sven and Laurent, do your affected systems have PackageKit installed? Yes, I also have packagekit installed
On Sun, 2025-04-27 at 16:18 +0200, Ben Hutchings wrote: [...] OK, so I think this is confirmed as somehow PackageKit-related. I had a look through the code for "apt update" and the PackageKit APT back-end to see what might be different. I think this has something to do with the different pkgAcquireStatus subclasses they use, but I couldn't identify a specific bug in PackageKit. I experimented with writing a test program that implements its own pkgAcquireStatus, and I I'm attaching the source for that. It needs to be run on a system where a local InRelease file is out of date. If you answer "no" to the Pulse() after the *second* time the InRelease file is reported done, that should reproduce the broken state. (The default answers are set for my VM snapshot which now has very outdated InRelease files, so I know that the Pulse() after a ReleaseInfoChanges() is the place to stop.) Ben.
Control: tag -1 confirmed Thanks, yes. I had a quick look at the code on Salsa from my phone: So when the fetcher stops (Pulse()=false cancels the update run), it runs the Finished method on each item. When the Finished() method of an InRelease file is called, it commits the transaction if it has started and there were no errors; that is, it does not check the transaction was actually complete.
Hi, I might be totally wrong, but could this also be related to what I'm seeing quite a bit lately on ci.d.n where apt-get update hangs after it reports an "Ign" for an InRelease file? For an example, see bug 1106279. Should that bug be reassigned to apt and/or merged with this bug? Paul https://bugs.debian.org/1106279
Hi there, I've been having the same issue on a laptop. In my case, the issue seems to have been that apt was interrupted (possibly a sudden shutdown due to empty battery) after the InRelease file was downloaded but before the the actual Packages files where updated. So, since the InRelease file was up to date, no list was checked and the obsolete ones where used. Removing the InRelease file fixes the issue in this case. It would be nice if APT could validate that the Package lists have actually been checked based on the current InRelease info, so that if this happen (interruption at a bad time), it checks the individual lists files even if the InRelease is unchanged. Another thing that could help would be a configuration option or a specific command to revalidate lists, something one could run routinely e.g once a month to avoid missing updates, or even a systematic validation of lists even though it can take more time when one uses compression - I would accept consuming a bit more CPU time and power to make sure systems are up to date, even if that's not the default. Cheers,
Hello, would it be better for this bug to be reassigned to packagekit? As was mentioned earlier, it seems like apt is working as expected - if there is no new InRelease file, it doesn't bother updating the index. The issue seems to be that packagekit is fetching the InRelease file but not the rest, leaving apt in an unexpected state. I just experienced this bug on 2 of my 4 Debian systems all of which had GNOME Software configured to automatically fetch updates. I regularly updated my systems from both the command line and through Software. However, the 2 that were not affected stay running 24/7 and have unattended-upgrades set up, which I imagine would refresh the package index before packagekit had a chance to break it (although I've disabled it now). The fix I found was to stop GNOME Software from automatically refreshing and downloading packages (time will tell if this fixes the issue going forward). In order to clear /var/lib/apt/lists/ I disabled all of my sources, ran apt update, and then re-enabled them. I imagine simply deleting the contents of the directory would work too. After that I started seeing the expected updates. Again, I feel that this is really a packagkit issue at heart, and perhaps it could be reassigned. Thanks, Jonathan
No, if Julian's explanation above is correct (and after a quick look at the code I have no reason to doubt that it is) then it's a bug in apt-pkg that just happens to be easily triggered by PackageKit.
I can confirm that it happened on my one machine with packagekit installed. It's slightly concerning since this is installed on a default desktop (gnome-core -> packagekit) and causes the package index to silently become stale and the machine not get security updates anymore. FWIW, this is also a fairly common occurrence on the #debian IRC channel. Usually because some package installation fails due to not existing in that version anymore.
Hello, Bug #1078608 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/dcc690d7e08f6d54fc10ee372510875a41ec9a3b ------------------------------------------------------------------------ pkgAcqMetaClearSig: Abort transaction when pkgAcquire::Run has been cancelled Ongoing Run can be cancelled by returning false from ::Pulse(). In this case the items would still be called pkgAcquire::Item::Finished() as usual, causing pkgAcqMetaClearSig to commit the incomplete transaction anyway as at that point it's still Started and has no errors. Add a pkgAcquire::Item::Cancelled() method and use it in pkgAcqMetaClearSig to abort the transaction. Closes: #1078608 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1078608
Hello, Bug #1078608 in apt reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/apt-team/apt/-/commit/244bf4d107d7f17eb7a21b036717a161618387ae ------------------------------------------------------------------------ pkgAcqMetaBase: Commit InRelease after other transaction items If apt update is interrupted during transaction commit, the system may end up with updated InRelease that does not match the other list files, which can cause apt to believe that the lists are already up-to-date when they are in fact not. Closes: #1078608 ------------------------------------------------------------------------ (this message was generated automatically) -- Greetings https://bugs.debian.org/1078608
We believe that the bug you reported is fixed in the latest version of
apt, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 1078608@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Julian Andres Klode <jak@debian.org> (supplier of updated apt package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 01 May 2026 18:40:52 +0200
Source: apt
Architecture: source
Version: 3.3.0
Distribution: unstable
Urgency: medium
Maintainer: APT Development Team <deity@lists.debian.org>
Changed-By: Julian Andres Klode <jak@debian.org>
Closes: 1078608
Changes:
apt (3.3.0) unstable; urgency=medium
.
[ Anders Kaseorg ]
* Fix Phased-Update-Percentage probability mistake
.
[ Simon Johnsson ]
* Scale history-list to screen width
* Optimize ShortenCommand
* Change GetKindString to not use .data() call
.
[ Julian Andres Klode ]
* Drop warning about unstable CLI interface.
A specific CLI version can now be requested using the --cli-version
flag, and old versions can be deprecated on a reasonable cadence.
Therefore, a warning is no longer necessary.
* hashes: Use std::span instead of std::basic_string_view
* sources.list(5): Document Contact/Bugs/Description fields.
Thanks to josch for the suggestion
* Require sqv for builds on supported archs and !pkg.apt.nosqv
.
[ Zheyu Shen ]
* fix apt patterns parsing bug for pre-depends
.
[ Herman Semenoff ]
* apt: funcs called with a string literal consisting of a single character
* apt-pkg/acquire: use range based for loop C++17
* apt: push to emplace C++11 if possible
* apt: modernize to make_unique C++17
* apt-pkg: methods: fixed many minor memleaks
.
[ наб ]
* sources.list(5): th[r]ough typo
.
[ Sebastian Krzyszkowiak ]
* acquire-item: Fix up the error message on committing aborted transaction
* pkgAcqMetaClearSig: Abort transaction when pkgAcquire::Run has been cancelled
(Closes: #1078608)
* pkgAcqMetaBase: Commit InRelease after other transaction items
(Closes: #1078608)
.
[ Daniel Lewart ]
* Fix bug reference
Checksums-Sha1:
09373ad161c09ada1e94da8b8b6e16d5fe50bb85 3132 apt_3.3.0.dsc
021c8ca0f0df59dc982da4f696de241ec17fef16 2477648 apt_3.3.0.tar.xz
aed4bd8e69324baac29e59f2f4bbca9f0a7f473d 7455 apt_3.3.0_source.buildinfo
Checksums-Sha256:
cb30e1e31e860ea1787e1ff0db1dcab7c4785b5e63dae1ac562a928049e42c99 3132 apt_3.3.0.dsc
23b47c69b1ca028f09d7e0fad53442096aec1c1f38595b9484baef18ae296345 2477648 apt_3.3.0.tar.xz
f57c65464b58c0d8a7f9a9c1026405df6b772c5948e5ac9c78e7b81476c82217 7455 apt_3.3.0_source.buildinfo
Files:
8f2202dc23c708a1479beecffc5bf279 3132 admin required apt_3.3.0.dsc
31c16658473df6acd5831f2193bb001b 2477648 admin required apt_3.3.0.tar.xz
c020ebacd9392132e780f5ed7f756bed 7455 admin required apt_3.3.0_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJDBAEBCgAtFiEET7WIqEwt3nmnTHeHb6RY3R2wP3EFAmn02A0PHGpha0BkZWJp
YW4ub3JnAAoJEG+kWN0dsD9x0RgP/ie7m5eUaLC9daPTFBUJXdGv8qmFc1KgZm1m
vD6t/qcH0ZQMQzz1A7rn/xk0aziIKt7T4G21in2V4iaT4gTcZ0HLAc/hBgrbVVcj
J1B10oINzHSBKdeQy08xw8PwHmRrQNnTjFY/sJcHkZ8NweEMs9IP0N49FxBltoL2
pue5dyiUl8PsVE298++7wwO8IsjSjW1BcM7QxmEc+juvV4zAuIFPDIydUT90VVS0
l4s7DVfKVDONz41a9M4fPvmFI6TsIUjpaH4QsSrIy/jsw2ZKxBG9bLqUtwudVyCc
odXkrTLR7z6B0JoWqyo0D4rxYKGyxup7fsNJN8dXFZzrF5AeSitf7Mgu5nqmYGkA
izdFqXIWdBpBh6LAXzHichQBTNOUEEbExtS7xOoRPXsU/IlnEul5duAg6dyhca/6
JnC931x6uZ97IKI4KAxL4W+N1F6idpd9fHqZLWYadk3/NdJbbtZS5D6Utw4I3NwY
ZgFyhSA5zQBcF8heSl21TeSAjY4YTUN145IMQqyyGyyXO/ncZKT+ZdaHNr+2DDBE
eD7K9duLoXgACd+X5FGBhJfZVUSYjmCgfwwrxmWjOL3nnJlpGuq+BcxOJRnv+NWk
gMxu0Qkgutf90+jeIOLC5AhIwdPKc0SwzCHDs7wdUggxwfv6PzL9GDuQ3ptP9tKD
Ws9K1lZO
=jglM
-----END PGP SIGNATURE-----
Would it be possible to backport this fix to apt 3.0 in stable? Volunteer support for trixie includes a lot of telling people to run `apt distclean` to work around this bug. Thanks sney
I'm not keen on touching the acquire code in stable releases given the severe regression potential without having said fixes in a stable release (whether Debian or Ubuntu) for a couple of months.