Summary: | we need app-crypt/gnupg-1.9 in order to replace newpg | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | SpanKY <vapier> |
Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | RESOLVED WORKSFORME | ||
Severity: | normal | CC: | andi-gentoo-bugs, avenj, clement.cc, craig, eric, fuzz, gentoo, greg_g, hanno, jkillius, jrray, jstuart, liquidx, polynomial-c, radek, seemant, shivapd, tawesley |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 41408, 43410 |
Description
SpanKY
![]() "NewPG is now GnuPG 1.9" http://lists.gnupg.org/pipermail/gnupg-devel/2003-August/020314.html "Newpg is no longer maintained, so it does not make much sense to fix it over there." (Werner Koch) suggestion: wont fix, change deps to not use newer libgcrypts, build an emerge for gnupg 1.9 (alpha code) (or ask taviso ;) i'd opt for the upgrade path (update app-crypt/gnupg to 1.9) ... *** Bug 37189 has been marked as a duplicate of this bug. *** All I was trying to do was get an openpgp plugin to work with kmail. My understanding was that newpg is required for that. If newpg is no longer supported, etc, how will the pgp plugin in kmail be supported in the future? yeah, thats exactly why i filed this in the first place ;) in the future you'll need to use app-crypt/gnupg-1.9 or better ... but we dont have that in the tree atm :x I'll make an ebuild and hardmask it, thanks for the info :) added and hardmasked, i'm considering slotting it, but as it uses the same configuration directory/keyrings and there are some strong warning about using it with your production keyring i decided against it for now. (of course you can configure these things on the command line, so maybe a wrapper script?). I'll use it for a while and think about it. if anyone as any thoughts, feel free to add them to this bug :) i dont believe SLOT-ing it is appropriate since it's just an unstable/dev version of the package masking is enough Does the 1.9 drop into the old configuration? Or is there a new mess of packages to get? Or is the 1.9 just absorbing newpg only? Basically, what will be the difference in the steps to make it work with Kmail as contrasted by the current howto? (also isnt the current dev release 2.3 or something now?)Help! *** Bug 39970 has been marked as a duplicate of this bug. *** *** Bug 40214 has been marked as a duplicate of this bug. *** *** Bug 40280 has been marked as a duplicate of this bug. *** *** Bug 41527 has been marked as a duplicate of this bug. *** Come on! Unmask it or hard mask libgcrypt 1.1.91 again, please... I don't consider this bug solved as the things are broken now in the standard (~x86) setup. Can somebody reopen, please? :-( Radek Welp, I hard masked libgcrypt in /etc/portage/package.mask with the following comment: # # OK since these fucking idiots at Gentoo have their heads up their asses and did NOT # BOTHER TO FUCKING TEST THINGS.... Let's take care of the problem with newpg and libgcrypt. # GEE GUESS WHAT... newpg ACTUALLY emerges. AMAZING. This bug is over a month old. The new ebuild is over 1 month old and hard masked still. There are no comments on here as to if it's a good idea to upgrade gnupg or not. There are shit pot loads of duplicate bugs filed. And yet... this bug is still marked as fixed. FIXED MY ASS. There is _no way_ I am removing the hardmask on an alpha version on something as important as gpg. Users rely on it to protect the integrity of their communications and their privacy. Bugs may still exist that could compromise their keyrings or encrypted messages, or whatever. I'll REOPEN and reassign to bug-wranglers. Jeff, please calm down. Being abusive doesn't help anyone. If this becomes a habit, I will have to suspend your Bugzilla access. Thanks. I'm sorry, but first of all ~x86 is NOT standard. x86, however, is. Second of all, Jeff Stuart -- tone it down, ok? We're volunteer devs working our asses off to provide you with something for free. Please keep it civilised, and minimise the abuse you give the developers, it's not necessary. Having said all that, I apologise for the kerfuffle caused by this, and I'll see to it we find some sort of resolution. Alastair, since you're listed as the maintainer of libgcrypt, can I have you pipe in with an opinion on how best to handle this? can't we just patch newpg to work with 1.1.91? the thing is, i never approved of adding 1libgcrypt-1.1.91, and i had initiated a take over of the package to prevent random people bumping the version without checking whether it breaks other things (in my case it was opencdk and gnutls). let me see what's involved first Ok, let me make a few comments here. A) While my comments were inappropriate... it should NOT have taken comments like that to get the response(s) from Seemant and Alastair. (And yes, I DO UNDERSTAND volunteering stuff, etc. I help track bugs for kopete and I KNOW how time consuming that is.) B) The thing that annoyed me was the fact that this bug essentially sat at fixed status for over 1 month while it was OBVIOUS there were problems with this. I am also annoyed because this explains why gpg-agent had broken on me a while ago without me even realizing it. Yet another case of emerge -U world biting me in the ass. :( Frankly, I had thought it was a problem with KDE and not GPG. file a new bug to track this properly, i dont want to look at crap like that if that doesnt suit you, well i dont care, my head is up my ass *** Bug 43332 has been marked as a duplicate of this bug. *** I'd like to ask that you consider slotting gnupg 1.9*. My reason is simple. Later versions contain gpgsm which KMail and other apps can use for S/MIME cert. management, etc. These tools are not available in earlier versions of gnupg. You can ever configure gunpg 1.9 not to install gpg... just gpgsm. It would be nice if I could use gpg 1.4 and gpgsm 1.9. I see that you've considered this before but I thought I'd ask anyway. |