Note that I'm confused myself between my wip packages and real, and the distfiles I create for wip.
I got a checksum mismatch for 2.8.4, and on downloading I see a mod date -rw-r--r-- 1 gdt users 6522704 Sep 10 14:17 /links/distfiles/nut-2.8.4.tar.gz but the tag v2.8.4 is from August 8: commit 541c2ecf0b2ec33dadb9f40b16acbe39042bd103 (HEAD, tag: v2.8.4-rc4, tag: v2.8.4) Author: Jim Klimov <[email protected]> Date: Fri Aug 8 12:48:39 2025 +0200 configure.ac: for now do not require (pre-)release tagged commits to build changelog by default - keep doing it on systems where we can though Signed-off-by: Jim Klimov <[email protected]> I had an older distfile, but it is missing commits that are in the tag, so I think it was somehow from my wip tarballs. So my questions are: Was the 2.8.4 tag ever moved, or has it (while it existed) always pointed to 541c2ecf0b2ec33dadb9f40b16acbe39042bd103? Was a 2.8.4 distfile created on August 8? are the current bits: $ digest sha1 /links/distfiles/nut-2.8.4.tar.gz SHA1 (/links/distfiles/nut-2.8.4.tar.gz) = a75056bf2ed4b4144fe14e40cea0dbd7e5a2582a $ ls -l /links/distfiles/nut-2.8.4.tar.gz -rw-r--r-- 1 gdt users 6522704 Sep 10 14:17 /links/distfiles/nut-2.8.4.tar.gz the same bits as were downloadable on August 8? Why is the mod date September 10? (And opinion, not clearly relevant to this situation at the moment, but relevant to many situations surprisingly often: Once a version tag is created, it must never be moved. Once a distfile is posted, it must never be changed, for any reason, no matter how much anyone thinks is a good idea. The same distfile name having different contents appears to be a supply chain attack. If there's a problem with a distfile, then only approach to fix that is to release a new distfile with a higher version. Integers are cheap and we don't run out of them. ) Thanks, Greg _______________________________________________ Nut-upsdev mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
