We need the following ebuilds stable for KDE 3.5.2 (see bug 120587): >=app-crypt/dirmngr-0.9.3 ~x86 >=dev-libs/libksba-0.9.13 ~x86 >=dev-libs/libassuan-0.6.9 ~x86 >=app-crypt/gpgme-1.1.2 ~x86 >=app-crypt/gnupg-1.9.0 ~x86 Please check if the ebuild are ready and invite arch herds as soon as possible.
Crypto, does anyone object to asking arch teams to mark stable (other than the blocker bug issue) ?
no objections here. Feel free to CC the arches you want. Arch testers: If there is a self test in gnupg-1.9.20-r1 that fails due to USE=-smime. This is harmless as the self test is for a smime program. Ref: https://bugs.gentoo.org/show_bug.cgi?id=131026#c5 app-crypt/gpgme-1.1.2-r1 is the same as app-crypt/gpgme-1.1.2 except --with-gnusm (smime stuff) forced instead of a USE flag. There is no logical change that would preclude a stabilization.
Please add app-crypt/pinentry to the list.
So should we start working on this or what?
Well as we have nothing left to stop this, let's dance ;) Please test and mark stable
Okay, stop for a minute, taviso raised objections, discussion on -dev is about to be started
I think splitting gnupg into gnupg2 gpgsm is a better idea, marking gnupg-1.9.x would be pretty dangerous. removing arches for now until these new packages are ready.
After some discussion on #gentoo-dev I added a new revision of gnupg-1.9.20 that has a gpg2-experimental useflag to not install the unstable gpg2. It is currently masked. Please test if it works ok.
Would the crypto herd take bug 13337 into account, please?
Bug #13337? I'm sure you meant another one. Anyway, I'm testing this new masked version on x86 and it works fine for signing/encrypting/decrypting. I say it is ready to go (at least on x86).
Full ack ;)
I've gone ahead and done the KEYWORDS for this stuff for x86. You'll probably want to unmask the newer gnupg revision, as I didn't touch that. I feel that is best left up to the maintainers.
On the gnupg homepage it is said clearly, that gnupg 1.9.x is the developer branch: "GnuPG 1.9 is the development branch of GnuPG with support for S/MIME." Since: the gnupg project is alive the devs aren't run over by a bus the devs are working on it and will release never versions It is not wise to mark software out of the developer branch as stable and to confuse others! This software IS developer software and 1.9 will never be released it will always be a developer branch, this has not to be added to a stable system! I see this as a security flaw, since gnupg checks signatures and provides integrity.
(In reply to comment #13) > It is not wise to mark software out of the developer branch as stable and to > confuse others! I fully agree. We should not mark developer snapshots/developer releases stable in Gentoo Portage when upstream doesn't consider the code ready for production use.
Well, the version that I marked stable is still masked, so if you guys feel like reverting the KEYWORDS, it shouldn't affect anyone (other than those that have unmasked it intentionally).
It is considered stable by upstream which is why this request went ahead. Refer URL.
Tavis, Henrik - upstream are happy. Are you?
So can I do amd64 yet? *grin*
(In reply to comment #17) > Tavis, Henrik - upstream are happy. Are you? That announcement is not reflected on their web site, which is where I checked. Thank you for clearing that up. Thumbs up from me :)
In that case... amd64 is done... =]
Shouldn't you guys add some arches?
Take 2: As per URL most of the gnupg-1.9 branch is stable. The gpg from gnupg-1.4 is still recommended for day to day use. This explains the odd dependency on it self and the gpg2-experimental USE flag. The stable targets are: =app-crypt/dirmngr-0.9.3 =dev-libs/libksba-0.9.13 =dev-libs/libassuan-0.6.10 =app-crypt/gpgme-1.1.2-r1 =app-crypt/gnupg-1.9.20-r3 From memory all these programs include good selftests.
(In reply to comment #10) > Bug #13337? I'm sure you meant another one. Sorry. Bug 133377.
Everything is now SPARC stable
Marked ppc stable.
alpha stable.
arm/hppa/mips/s390: *bump* on stabilization. See commment 22 for the list.
may I ask why gnupg-1.9 has gnupg-1.4 as a dependency? That looks a bit confusing. I monitor duplicate packages through emerge -p -P, and I couldn't figure out which was the package requiring gnupg-1.4, until I figured out it was gnupg-1.9 itself ;). "equery depends gnupg" doesn't show gnupg as a dependency on itself, that's why I couldn't figure it out (I had to read the .ebuild to figure it out for sure). Perhaps the rdependency is what requires it? Does it mean gpg-1.9 requires 1.4 to be installed in order to build? Shouldn't then 1.4 be deleted completely from the system instead of hanging around in emerge -p -P listing?
(In reply to comment #28) > may I ask why gnupg-1.9 has gnupg-1.4 as a dependency? Earlier versions of gnupg-1.9 (<1.9.92) needed gnupg-1.4 to provide the full compliment of service. http://lists.gnupg.org/pipermail/gnupg-announce/2005q4/000209.html > That looks a bit confusing. Yes - thankfully the upstream have merged 1.4 codebase into 1.9.92 http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000236.html > Does it mean gpg-1.9 requires 1.4 > to be installed in order to build? no - its a RDEPEND > Shouldn't then 1.4 be deleted completely no - not fully stable - see 1.9.92 annoucement
HPPA done.
Nothing left to do here...