Following up again, after looking even harder. ftp.netbsd.org caches distfiles for packages, so people can fetch them if upstream goes away, and to meet GPL source obligations (a formality in the nut case).
In the cache was: -rw-rw-r-- 1 gdt wheel 6522262 Aug 14 08:09 nut-2.8.4.tar.gz SHA1 (ftp.netbsd.org/nut-2.8.4.tar.gz) = aed1db6ffcdbbc42259a0fcb5ababfd45b5d2c7a SHA512 (ftp.netbsd.org/nut-2.8.4.tar.gz) = 0d87c0006608f92ae54f8a500f93d9a81eac1d9abf57f32e7718dd72f265b8293a0b6cdba04c802b81eaf8907b52669c36b47b6875a4377f9752845ac6c5e8fa and fetched on my machine after removal -rw-r--r-- 1 gdt users 6522704 Sep 10 14:17 gdtlocal/nut-2.8.4.tar.gz SHA1 (gdtlocal/nut-2.8.4.tar.gz) = a75056bf2ed4b4144fe14e40cea0dbd7e5a2582a SHA512 (gdtlocal/nut-2.8.4.tar.gz) = ddaca1d0cba17817fd27d036442395d11d64541b0782cd3c33d7b93712a15587dbad54fd7ed8a3ff14b89d75211560f76c30f5b9559e963adb4df7b05b66ec26 Diffing them, they were both produced on a machine with autoconf 1.16.5 (vs one produced for pkgsrc-wip testing on my machine which is 1.18). The file "scripts/Windows/Makefile" encodes paths to the dir used to generate the tarball via "missing" scripts so I can tell from a distfile whether it was produced by 'jim' or 'gdt' :-) Between the two signs, I am confident that neither of the above was produced by me. This basically rules out "gdt/netbsd got confused by a distfile generated for wip by gdt". Diffing the cached tarball and a tarball fetched recently, I see --- ftp.netbsd.org/nut-2.8.4/ChangeLog 2025-08-08 04:42:34.000000000 -0400 +++ gdtlocal/nut-2.8.4/ChangeLog 2025-08-08 07:06:22.000000000 -0400 @@ -1,7 +1,27 @@ -NOTE: This change log section represents git commits in range 'v2.6.0..HEAD' (commits '8103b4e5c..434cb36a3'). +NOTE: This change log section represents git commits in range 'v2.6.0..HEAD' (commits '8103b4e5c..541c2ecf0'). 434cb36a3 is v2.8.4rc1 541c2ecf0 is v2.8.4rc4 So I wonder, was the rc1 tarball present -- with the name nut-2.8.4.tar.gz -- on the download server? On the NetBSD ftp server, the rc1-flavored copy of nut-2.8.4.tar.gz has mod time Aug 14 12:09 nut-2.8.4.tar.gz ctime Aug 17 12:16 nut-2.8.4.tar.gz so August 17 is when it would have been fetched. I just committed to pkgsrc a change to the checksums, thinking it was my confusion about the old one: -BLAKE2s (nut-2.8.4.tar.gz) = ece7b19f55771472f113a712d047ff324199d28ea0f2f5cfa13a781ff8947e78 -SHA512 (nut-2.8.4.tar.gz) = 0d87c0006608f92ae54f8a500f93d9a81eac1d9abf57f32e7718dd72f265b8293a0b6cdba04c802b81eaf8907b52669c36b47b6875a4377f9752845ac6c5e8fa -Size (nut-2.8.4.tar.gz) = 6522262 bytes +BLAKE2s (nut-2.8.4.tar.gz) = 2225617ef46a46cc0b6e08b93877ad0391b44a349efa2c8ea82fb3ef5ca8f7d2 +SHA512 (nut-2.8.4.tar.gz) = ddaca1d0cba17817fd27d036442395d11d64541b0782cd3c33d7b93712a15587dbad54fd7ed8a3ff14b89d75211560f76c30f5b9559e963adb4df7b05b66ec26 +Size (nut-2.8.4.tar.gz) = 6522704 bytes and the SHA512s in that diff match the cached distfile fetched on August 17, and the one I re-fetched on Sep 16 11:39. If the rc1 distfile was present under the name nut-2.8.4.tar.gz, and was replaced, it would be good to understand, since otherwise there is perhaps some mysterious bug in the fetching/etc. infrastructure. Could people with downloaded nut-2.8.4.tar.gz files check the SHA1/512 values and see which one they have? Was there some plan to have rc tarballs on the ftp server but under the name nut-2.8.4.tar.gz? I am guessing no, but I am having trouble guessing what happened. _______________________________________________ Nut-upsdev mailing list Nut-upsdev@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsdev
