While (re-)emerging net-wireless/bluez-4.75 as part of net-print/cups post-install message, a checksum error occurred. However, upon reemerging the package (via emerge --resume --keep-going) it successfully redownloaded the file And I'm not the only one who has run into this: http://forums.gentoo.org/viewtopic-t-852512.html . I didn't need to resync, though.
Created attachment 254175 [details, diff] Diff of corrupted file 0C375F diff the correct vs incorrect file (according to portage, anyway)
I guess some mirrors have an outdated copy of the file, since the digest got updated for bug 344815. Anyway, oui.txt on the master mirror appears to have the same sha1sum as the one in the current manifest: $ sha1sum /mnt/distfiles/distfiles/oui.txt 3315f34ed4f46f87d1fc9b1d0fc656c39d59e5fb /mnt/distfiles/distfiles/oui.txt
Here's a working link for the file whose checksums are in the manifest: http://gentoo.osuosl.org/distfiles/oui.txt
Looks like upstream changed it yet again. jer@bastiaan /newaches/gentoo/cvs/gentoo-x86/net-wireless/bluez $ ebuild bluez-4.77.ebuild fetch Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... * bluez-4.77.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Downloading 'http://ftp.snt.utwente.nl/pub/os/linux/gentoo/distfiles/oui.txt' --2010-11-23 15:50:21-- http://ftp.snt.utwente.nl/pub/os/linux/gentoo/distfiles/oui.txt Resolving ftp.snt.utwente.nl... 130.89.149.20, 2001:610:1908:a000::149:20 Connecting to ftp.snt.utwente.nl|130.89.149.20|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 2282383 (2.2M) [text/plain] Saving to: `/aches/distfiles/oui.txt' 100%[=================================================================================================>] 2,282,383 2.11M/s in 1.0s 2010-11-23 15:50:22 (2.11 MB/s) - `/aches/distfiles/oui.txt' saved [2282383/2282383] * oui.txt RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] jer@bastiaan /newaches/gentoo/cvs/gentoo-x86/net-wireless/bluez $ rm /aches/distfiles/oui.txt* -v removed `/aches/distfiles/oui.txt' jer@bastiaan /newaches/gentoo/cvs/gentoo-x86/net-wireless/bluez $ GENTOO_MIRRORS="" ebuild bluez-4.77.ebuild fetch Appending /newaches/gentoo/cvs/gentoo-x86 to PORTDIR_OVERLAY... * bluez-4.77.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] >>> Downloading 'http://standards.ieee.org/regauth/oui/oui.txt' --2010-11-23 15:50:42-- http://standards.ieee.org/regauth/oui/oui.txt Resolving standards.ieee.org... 140.98.193.16 Connecting to standards.ieee.org|140.98.193.16|:80... connected. HTTP request sent, awaiting response... 301 Moved Permanently Location: http://standards.ieee.org/develop/regauth/oui/oui.txt [following] --2010-11-23 15:50:42-- http://standards.ieee.org/develop/regauth/oui/oui.txt Reusing existing connection to standards.ieee.org:80. HTTP request sent, awaiting response... 200 OK Length: 2290876 (2.2M) [text/plain] Saving to: `/aches/distfiles/oui.txt' 100%[=================================================================================================>] 2,290,876 1.32M/s in 1.7s 2010-11-23 15:50:47 (1.32 MB/s) - `/aches/distfiles/oui.txt' saved [2290876/2290876] ('Filesize does not match recorded size', 2290876L, 2282383) !!! Fetched file: oui.txt VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 2290876 !!! Expected: 2282383 Refetching... File renamed to '/aches/distfiles/oui.txt._checksum_failure_.Mf9rBy' !!! Couldn't download 'oui.txt'. Aborting.
Have just regenerated the digest to match current oui.txt file, I have also prepared a local script to test this problem periodically
(In reply to comment #5) > Have just regenerated the digest to match current oui.txt file, I have also > prepared a local script to test this problem periodically You might want to do something like SRC_URI="http://standards.ieee.org/regauth/oui/oui.txt -> oui-20101123.txt" and bump the date there each time you update the manifest. That way mirrors that are out of date will simply return 404 error for the new name instead of serving a file with the same name and the wrong checksum.
(In reply to comment #6) > (In reply to comment #5) > > Have just regenerated the digest to match current oui.txt file, I have also > > prepared a local script to test this problem periodically > > You might want to do something like > SRC_URI="http://standards.ieee.org/regauth/oui/oui.txt -> oui-20101123.txt" and > bump the date there each time you update the manifest. That way mirrors that > are out of date will simply return 404 error for the new name instead of > serving a file with the same name and the wrong checksum. > Looks better to me, thanks a lot, will take care of this in the next bump (when I have time) Reopening to remember the issue
+*bluez-4.80 (25 Nov 2010) + + 25 Nov 2010; Pacho Ramos <pacho@gentoo.org> -bluez-4.69.ebuild, + +bluez-4.80.ebuild: + Version bump with multiple upstream fixes, also handle oui.txt file + downloading in a better way as suggested by Zac in bug #345263, update + HOMEPAGE, remove .la files, and fix cups location (bug #346033 by Florian + Steinel). Remove old. +
*** Bug 349302 has been marked as a duplicate of this bug. ***
Created attachment 263623 [details] net-wireless/bluez-4.82 build.log Hello, This bug has not really been resolved. I have been trying to emerge bluez for several months now, always failing. Portage tries to download the file oui-20101219.txt from multiple sites which fail with 404 errors (not surprisingly, as per Comment #7, but why is the file not on the mirrors?), and in the end it finds oui.txt (this time without a date suffix, not surprisingly) on IEEE's site. This time the file downloads but, again not surprisingly, the checksum fails. I am attaching the build log. As far as i can tell, the problem would go away if the correct dated version of oui.txt was on the Gentoo mirrors. I have no clue why this is not the case...
4.87 should solve this (but I don't know why oui-20101219.txt has been removed from mirrors :-/)
Thanks Pacho, 4.87 as well as 4.89 indeed emerge without problems. Perhaps a bump is due?
It needs to be stabilized -> bug 356255
