Thanks Reproducible: Always
Tested on x86; With USE="cups" I get; * package net-wireless/bluez-4.80 NOT merged * * Detected file collision(s): * * /usr/libexec/cups/backend/bluetooth * * Searching all installed packages for file collisions... * * Press Ctrl-C to Stop * * None of the installed packages claim the file(s). Then I removed /usr/libexec/cups/backend/bluetooth and it installed fine. I did not test with a bluetooth device.
(In reply to comment #1) > Tested on x86; > With USE="cups" I get; > > * package net-wireless/bluez-4.80 NOT merged > * > * Detected file collision(s): > * > * /usr/libexec/cups/backend/bluetooth > * > * Searching all installed packages for file collisions... > * > * Press Ctrl-C to Stop > * > * None of the installed packages claim the file(s). > > Then I removed /usr/libexec/cups/backend/bluetooth and it installed fine. I did > not test with a bluetooth device. > If I don't misremember it's not a problem when "none of the installed packages claim the file"
Stable for HPPA.
arm stable
amd64 done
In support of the existing x86 testing, I did basic tests with a bluetooth device and it worked fine. I would say: x86 OK.
Location: http://standards.ieee.org/develop/regauth/oui/oui.txt [following] --2011-01-08 11:34:22-- 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: 2316046 (2,2M) [text/plain] Saving to: `/usr/portage/distfiles/oui-20101126.txt' 100%[======================================>] 2.316.046 52,7K/s in 67s 2011-01-08 11:35:32 (33,7 KB/s) - `/usr/portage/distfiles/oui-20101126.txt' saved [2316046/2316046] ('Filesize does not match recorded size', 2316046L, 2291761) !!! Fetched file: oui-20101126.txt VERIFY FAILED! !!! Reason: Filesize does not match recorded size !!! Got: 2316046 !!! Expected: 2291761
That shouldn't occur per: http://bugs.gentoo.org/show_bug.cgi?id=345263#c6 since 4.80 already uses that logic. Zac, do you have any idea about what could be causing that solution to not work? Thanks a lot :-)
Comment #7 shows it fetching directly from ieee.org. That's unusual. It's not a problem when it fetches from the mirrors as usual.
(In reply to comment #9) > Comment #7 shows it fetching directly from ieee.org. That's unusual. It's not a > problem when it fetches from the mirrors as usual. A clever way to avoid this issue is to put mirror://gentoo/oui-20101126.txt in SRC_URI. That way, even if the user has a poor GENTOO_MIRRORS setting, fetching will still fall back to the "gentoo" mirrors defined in $PORTDIR/thirdpartymirrors.
x86 done. Thanks everybody. Christians failure is a classical case of 'upstream changed distfile without proper versioning'. (See also bug #345043 ) The manifest contains the hash for the version on the mirrors, upstreams version is different.
(In reply to comment #11) > x86 done. Thanks everybody. > > Christians failure is a classical case of 'upstream changed distfile without > proper versioning'. (See also bug #345043 ) > > The manifest contains the hash for the version on the mirrors, upstreams > version is different. > But I would prefer to not have to update mirrored file with upstream one from time to time since size changes without noticing by upstream :-| Then, maybe I would prefer Zac suggestion from comment #10
If the license permits, just host the file on your devspace. (See also the following flamw... err. thread: http://archives.gentoo.org/gentoo-dev/msg_988b3567c1db5eab9acb2d5b6a3076c5.xml )
(In reply to comment #13) > If the license permits, just host the file on your devspace. (See also the > following flamw... err. thread: > http://archives.gentoo.org/gentoo-dev/msg_988b3567c1db5eab9acb2d5b6a3076c5.xml > ) > Umm, ok, it's a bit more tedious than simply updating SRC_URI but, if it's preferred, will do it in the next bump -> This means for remaining arches on this bug that they should go ahead anyway with stabilization ;-)
On last question is: Currently, the following is stated in SRC_URI: SRC_URI="mirror://kernel/linux/bluetooth/${P}.tar.gz http://standards.ieee.org/regauth/oui/oui.txt -> oui-${OUIDATE}.txt" Then, if I start to provide it also in my devspace, should I still try to download it at first from original location simply adding my devspace entry after http://standards.ieee.org? Or should I only rely on the copy from my devspace? Thanks a lot
(In reply to comment #15) > On last question is: > Currently, the following is stated in SRC_URI: > > SRC_URI="mirror://kernel/linux/bluetooth/${P}.tar.gz > http://standards.ieee.org/regauth/oui/oui.txt -> oui-${OUIDATE}.txt" > > Then, if I start to provide it also in my devspace, should I still try to > download it at first from original location simply adding my devspace entry > after http://standards.ieee.org? Or should I only rely on the copy from my > devspace? Thanks a lot I would drop the ieee source from SRC_URI because there is zero chance that they will put up a working version there. I would leave the original URL in a comment in the ebuild with some explanation why we host this file ourselves.
(In reply to comment #16) > (In reply to comment #15) > > On last question is: > > Currently, the following is stated in SRC_URI: > > > > SRC_URI="mirror://kernel/linux/bluetooth/${P}.tar.gz > > http://standards.ieee.org/regauth/oui/oui.txt -> oui-${OUIDATE}.txt" > > > > Then, if I start to provide it also in my devspace, should I still try to > > download it at first from original location simply adding my devspace entry > > after http://standards.ieee.org? Or should I only rely on the copy from my > > devspace? Thanks a lot > > I would drop the ieee source from SRC_URI because there is zero chance that > they will put up a working version there. I would leave the original URL in a > comment in the ebuild with some explanation why we host this file ourselves. > This should be solved in 4.87, thanks a lot :-)
Remaining arches please go to bug 353034 directly
