Bugzilla Bug 132343

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...