I am unable to find this file on any gentoo distfiles mirror, and thus I am unable to emerge truecrypt. I have tried several different mirrors using mirrorselect. I don't know if it's relevant, but I did find this message on euscan (http://euscan.iksaif.net/package/app-crypt/truecrypt/): * mirror://gentoo/truecrypt-pkcs11.h.bz2 is blacklisted by rule mirror://gentoo/(.*)
This bug is obvious, as the ebuild is fetch restricted and nothing in SRC_URI will therefore be mirrored or even downloaded. pkg_nofetch() needs to be extended, I guess.
Where can i find pks11? ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20 Is this the correct Source, and how to pull it in to the distfiles?! Because there is no bz2.
Please do NOT CC arches on your own, there is no reason for us to be here.
Created attachment 323698 [details] missing truecrypt-pkcs11.h.bz2 file
I've attached the missing file, recreated from [1], for others who encounter this bug to use as a temporary measure. 1. http://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute.git;a=blob;f=src/pkcs11.h;h=03e904b763d84cd738b83a14bff8b97637fbd740;hb=HEAD
Thanks for the temporary fix, Nathan. Devs: If this bug is 'obvious', can a dev with the knowledge of the right team consider opening a bug/enhancement suggestion elsewhere to add an automated procedure to check or warn devs when creating or checking in ebuilds that may repeat the bug? Thanks.
*** Bug 435582 has been marked as a duplicate of this bug. ***
*** Bug 436994 has been marked as a duplicate of this bug. ***
Hi guys. When will truecrypt work ? Thanks. We are waiting... very very are waiting ))) Thanks.
I have readded pkcs11.h.bz2 to the mirrors and whitelisted it for SIX (6) months. We need a better solution by then.
Just don't put on the frigging mirrors, but in your devspace.
(In reply to comment #11) > Just don't put on the frigging mirrors, but in your devspace. If the ebuild has fetch restrictions turned on will that still help? I thought it wouldn't and so I followed this guide to put the file back on the mirrors since those are always checked. http://www.gentoo.org/proj/en/infrastructure/mirrors/overview-distfile.xml
It'll still require a manual fetch BUT it won't be deleted _if it's in your devspace_. So just do that. I'm seriously thinking of asking for mirror://gentoo/ to be banned in tree.
(In reply to comment #13) > It'll still require a manual fetch BUT it won't be deleted _if it's in your > devspace_. So just do that. > > I'm seriously thinking of asking for mirror://gentoo/ to be banned in tree. That is the issue though, there are two files needed for the ebuild and only one of them requires manual fetch so this seems to functionally solve the issue for now. by no means is it the _right_ solution but since no one has cared to fix this in the 2+ months the bug has been opened I stepped up and did something I hope will help. in reality pkcs11.h needs to be split off into a separate package (and probably a virtual) but that is a bit more than I can handle as I'm not really up to speed on this package. hopefully this hack gives me enough time to fix it properly or at least motivate the maintainer to do so. That or we could p.mask it or leave it broken and pretend we don't care about our users.
Definitely pkcs11 should be provided outside of this, I think p11kit already does something like that, Alon would know better and he's rejoining. Yes, we do need a better support for partly-fetch-restricted packages. OTOH whitelisting it on the mirror is just working around a different problem.
Added: * Please execute: * curl 'http://git.gnupg.org/cgi-bin/gitweb.cgi?p=scute.git;a=blob_plain;f=src/pkcs11.h;hb=38bdba0bb1ab93950489c645938c93ed577f9139' > /var/gentoo/distfiles/truecrypt-7.1a-pkcs11.h
Would you be kind enough to explain the changes to me so I can understand how you fixed it? I don't see anything that looks like it would fix anything in your change set...
(In reply to comment #17) > Would you be kind enough to explain the changes to me so I can understand > how you fixed it? I don't see anything that looks like it would fix > anything in your change set... Sure. As portage does not support fetch restriction per URI, I kindly ask the user to download the pkcs11.h as well.
So I guess the six months is up and the problem is back. Can this be fixed?
Yes, it can be fixed. For right now I'll just throw this file in my homedir and point the ebuild at it. This should keep it on the mirrors. I welcome any and all other suggestions to fix this issue, for now I'm fixing user visible breakage the best way I (currently) know how.
Alon, I dropped the file back on the mirror to aid people as much as possible. I think there would be improvement if we just host the file in a homedir or something like Diego suggested. I will still randomly drop off the mirrors but I see no reason it can't just fail the mirror and successfully download from dev.gentoo.org. The way you have the ebuild now it seems it refuses to download the file no matter what so I'm asking your opinion before I go randomly changing something you obviously put effort into.
(In reply to Rick Farina (Zero_Chaos) from comment #21) > Alon, > > I dropped the file back on the mirror to aid people as much as possible. I > think there would be improvement if we just host the file in a homedir or > something like Diego suggested. I will still randomly drop off the mirrors > but I see no reason it can't just fail the mirror and successfully download > from dev.gentoo.org. > > The way you have the ebuild now it seems it refuses to download the file no > matter what so I'm asking your opinion before I go randomly changing > something you obviously put effort into. I do not understand, there is a manual fetch instructions for two files, and we discuss one? This issue is fixed as far as portage can handle. You should fetch two files per the pkg_nofetch instructions.
> This issue is fixed as far as portage can handle. You should fetch two files > per the pkg_nofetch instructions. We probably could let portage fetch the one file like it used to....
(In reply to Rick Farina (Zero_Chaos) from comment #23) > > This issue is fixed as far as portage can handle. You should fetch two files > > per the pkg_nofetch instructions. > > We probably could let portage fetch the one file like it used to.... How? this was the problem? we cannot mix manual and automatic fetch in SRC_URI... If we could there was no problem to fetch the file directly from upstream repo.
Looks like the the gnupg project disabled their git repos. Any link from http://git.gnupg.org/ leads to a "no projects" page.
Their repos are offline due to server trouble. They will be back.
