Am Wed, Apr 16, 2025 at 11:23:03AM +0200, schrieb Laurent Bigonville:
On Tue, 13 Aug 2024 19:57:58 +0200 Sven Bartscher <kritzefitz@debian.org> wrote:
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
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.
I enabled debugging in apt (Debug::Acquire::http=true) and I see the following:
GET /debian/dists/unstable/InRelease HTTP/1.1
[…]
If-Modified-Since: Wed, 16 Apr 2025 08:18:27 GMT
Answer for: http://ftp.be.debian.org/debian/dists/unstable/InRelease HTTP/1.1 304 Not Modified
Date: Wed, 16 Apr 2025 09:07:23 GMT
Server: Apache/2.4.62 (Debian)
Last-Modified: Wed, 16 Apr 2025 08:18:27 GMT
[…]
-rw-r--r-- 1 root root 302323 15 avr 04:01 ftp.be.debian.org_debian_dists_unstable_contrib_binary-amd64_Packages
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).
severity 1078608 serious
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmgBa6EACgkQMRvlz3HQ eIMP3Q/9G3xT0TWCQ0JnK99Gw1s6hucgZzuWltM6C/tACElQZG8qR8rUPQ8MaAb0 hmqxe9BMLbW8paFHthjYRzR+1d6kbMXgLAzrvEOlP/aPGlb6QqlHe66RNohUbksr VdViXmTBmEfD5/qw88cwSMocSybOw+cSC+9E6xp6l51h6tURohOaVabaW9Ufi5lh euDHD3k2wXzGg0lDasVkj/x2F0mODZS3OnVWRPrICjo4pupHTSVuBAgc5Fe+YRxs j9x2v2Kg7WlxDhkyn32rofnCXhEPBamrFRHEzCBDrnWElhtXtdKLR9AWlFbJ2+6G 5VtHNY93ecBDoN4Ovtg/nNb/Kb5fD8Tq/XsM8zzqd+mtYSvDRDpdcQwzRohJGLJG JNxzosDvZQj73oWoYcqxkIQacyjMFSmDk7r1EOXZIjjaU3o5L6iRV5H8m1psteHN +6xGdfo0HfGw24bqkxfgGdje6VoYqOViUq5bpZvcIJQisdYiuggy1YQtSPjbYiN4 kfSDB0pJ3F1U22iqDSZZ02QDWSc6dnVqyvPsnL/sv2JblnqaWkC9aqCWv9HyC7cJ 3X8yjTPSMBXyqdLOdBpF2+o1DWXB98jF3LJgLmInI6pQGaEj/dujZfLq+BlpgKdh mXIOJ5LktbA2MRZceiirg83KRHoKNcYGuQR7DzkuAN3FIXGfHdM=
=hwBD
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)