Am Wed, Apr 16, 2025 at 11:23:03AM +0200, schrieb Laurent Bigonville: > On Tue, 13 Aug 2024 19:57:58 +0200 Sven Bartscher <kritzef...@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
signature.asc
Description: PGP signature
