Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

It seems 2.0.1 should be slotted. Apps like seahorse dep on gnupg 1.2.x or
1.4.x. The upgrade of gnupg to 2.0.1 causes breakage, and therefore should be
slotted.

GnuPG-2 has a different architecture than GnuPG-1 (e.g. 1.4.5) in that
it splits up functionality into several modules.  However, both
versions may be installed alongside without any conflict.  In fact,
the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching.  The
advantage of GnuPG-1 is its smaller size and the lack of dependency on
other modules at run and build time.  We will keep maintaining GnuPG-1
versions because they are very useful for small systems and for server
based applications requiring only OpenPGP support.

2.0.x needs to be in slot1 please thanks

There is no point in keeping both versions installed.
gpg-2.X series is a full replacement gpg-1.X series.

> The upgrade of gnupg to 2.0.1 causes breakage

Which? Can you please explain?

>> Comment #2
In this case, someone needs to fix the app-crypt/seahorse dependency (in
offical portage and gentopia overlay please).

The points for keeping both versions were covered in detail in Comment #1.

With regard to seahourse it's not a dependency issue. Seahorse requires 1.2.x
or 1.4.x per upstream.
checking for appropriate GnuPG version... configure: error: Appropriate version
of GnuPG not found. Please install version 1.2.x or 1.4.x

Introducing 2.0.1 without a slot has caused unacceptable breakage. Which it
seems no one looked into, or resolved before 2.0.1 was committed. Not to
mention circular deps. Since one would emerge 1.4.x for seahorse, then portage
would pull in 2.0.1. Then one has to go emerge 1.4.x again, and so on.

So there are multiple reasons to slot, and it needs to be done, not debated.
Once packages like seahorse or others are modified upstream to use or work with
2.0.1 then it will be moot. But that time is not now, and you can't go and
break packages that used to work and install. Just because your moving forward
with a dep.

Now again per comment #1 there are reasons to keep the 1.x packages around. So
it's not likely they can be removed from tree anytime soon. Please slot this
package to fix the resulting breakage that has occurred. Thank you.

(In reply to comment #2)
> There is no point in keeping both versions installed.
> gpg-2.X series is a full replacement gpg-1.X series.
> 
> > The upgrade of gnupg to 2.0.1 causes breakage
> 
> Which? Can you please explain?
> 

It is not a point of which the slot needs to be fixed. If you do not wish to do
I will speak with dragonheart about fixing it. The reason being not all
applications want/need version 2 some of us need version one for server stuff
while using version 2 for other stuff hense upstream ensured we could install
it slotted.

(In reply to comment #5)
> It is not a point of which the slot needs to be fixed. If you do not wish to
> do I will speak with dragonheart about fixing it. 

Go ahead... Are you trying to frighten me?

> The reason being not all
> applications want/need version 2 some of us need version one for server stuff
> while using version 2 for other stuff hense upstream ensured we could install
> it slotted.

Nobody is going to remove 1.X series.
If you like to install it you may mask >=app-crypt/gnupg-2.0.0
There is no point in installing the TWO (means slot) at the same time.
The above reason is not a good enough reason to slot.
Please try to find some other.

---

Crypto herd, please comment here...

If we want to slot gnupg, we need also:
1. Create virtual/gnupg.
2. Create and maintain eselect-gnupg to allow selecting the right version.
3. Modify gnupg-1.X ebuild so it install gpg1, gpgv1 so that we can link gpg,
gpgv to the right product version.
4. Update all ebuilds to depend on virtual/gnupg instead of explicit version.

But I really don't see any reason to do so, since there is no point in
installing both versions at the same time.

Wasn't so much a scare tactic, as it was there is breakage that needs to be
fixed.

Please understand upstream has developed GnuPG-2 to be able to co-exist with
GnuPG-1.

http://lists.gnupg.org/pipermail/gnupg-announce/2006q4/000242.html

"However, both versions may be installed alongside without any conflict.  In
fact, the gpg version from GnuPG-1 is able to make use of the gpg-agent as
included in GnuPG-2 and allows for seamless passphrase caching. "

It seems GnuPG-1 can also use and benefit from GnuPG-2 being present. So there
is reason and justification to have both present. Granted I am not aware of an
app or situation where both would be required at this time.

Other than to support legacy and current apps. As in the current situation to
remedy breakage. It's possible seahorse will never use GnuPG-1 as upstream is
not deprecating it's use, or phasing it out. It seems there will be further
development and releases of GnuPG-1.

Bottom line, the package has cause breakage in the tree which must be resolved.
However ever you want to resolve it. Previous comments weren't meant for
intimidation. They were meant to express the breakage must be fixed, and if you
don't want to fix the breakage. Others can and will, because breakage is not
acceptable.

If virtuals, eselect, and etc are required to properly slot the package in your
view. Then the package should have been kept in an overlay or packaged masked
and developed further before introducing to the tree or unmasking.

Changing severity to blocker on behalf of Anarchy.

(In reply to comment #6)
> (In reply to comment #5)
> > It is not a point of which the slot needs to be fixed. If you do not wish to
> > do I will speak with dragonheart about fixing it. 
> 
> Go ahead... Are you trying to frighten me?
> 
Dude I used to be part of crypto herd ... I know the importants of slotting it.
If you do not like the fact that it needs to be slotted then maybe someone else
in herd should maintain it. Dragonheart is the lead last I checked for crypto
herd so if you have proplems with people speak to the lead of a herd then maybe
gentoo is not right for you. Your attitude stinks, a little heads up "I was
retired when I thought my shit did not stink" keep pushing on devs and users
and your life with gentoo wont be long, make sure you think before you speak.

Alon:
Why can't this be simply slotted? Upstream designed it to work side by side. So
we should respect that

I go on a short vacation, and all hell breaks lose? Chill out people.

Prior to 2.0, 1.9 contained the new development stuff (mainly agent and
S/MIME), and was installed in parallel to 1.4, because upstream recommended
that people use the 1.4 series for relibable OpenPGP (so they could break
S/MIME if they had to).
Thus 1.4 and 1.9 were slotted.

As of 2.0, the OpenPGP code is stable development again (no changes that break
it are allowed).

Most critically, you wherever you previously used GnuPG-1.4, you can use
GnuPG-2.0.

Seahorse DOES need changing, but it's simply a fix for configure to stop it
complaining about a GnuPG version it doesn't know about. It took me just 5
minutes to write up a patch for seahorse's configure. It passes make check, but
I can't fully test right now, as my GNOME config is broken. It will be commited
later tonight.

alonbl: there is one problem you have re-introduced. Please REMOVE usage of
capabilities: FORCE --disable-capabilities to be used. They are NOT needed for
any kernel newer than 2.6.9 and 2.4.?? (I forget which one), and this lead to
the previous problems of a circular reference to kernel sources, and thus we
removed the kernel_check stuff in the GnuPG that JUST went stable this last
week.

Updating seahorse is fine by me :) Fixing breakage is the primary concern.

Upstream will still develop both GnuPG-1 and GnuPG-2. GnuPG-1 seems ideal for
server side apps and embedded. Masking GnuPG-2 is one way to go to get that
functionality. If there is never a situation where both would be required, then
it can serve as a long term solution. Just would seem odd for upstream to state
they could co-exist, then not provide that option to users or etc.

Either way, it's all pretty old now. So long as seahorse, and any other
breakage is addressed. The rest is moot as far as I am concerned :)

Note: At one point enigmail (I believe) was said to be broken. Given the amount
of deps, I would be curious if other packages have any issues.

(In reply to comment #11)
> alonbl: there is one problem you have re-introduced. Please REMOVE usage of
> capabilities: FORCE --disable-capabilities to be used. They are NOT needed 

Done.

(In reply to comment #8)
> Changing severity to blocker on behalf of Anarchy.

Is there any reason leaving this as blocker?

ok, the seahorse patch works.
There was a another check inside seahorse-agent that had 1.* hardcoded, and
after I modifed that everything works (I created a key, and gave the operations
a quick spin).

I have commited it to the tree now.

The 'modules' that are discussed are the following libraries:
libgcrypt, libksba, libgpg-error, libassuan.
1.4 bundled static copies of them, and could not use external variants to
build.
As other parts of the Gentoo tree brings these packages in as well, having 2.0
as the default (so no 1.4 and 1.9) reduces the overall size of a system.

Grepping the tree quickly, seamonkey (because of enigmail) and enigmail are the
only packages that declare a dep on GnuPG-1.4 explictly.

I'm not a TB user, so I'd appreciate if somebody could give enigmail a spin to
see if it works.

Works with TB 1.5.0.9 here

(In reply to comment #15)
> Grepping the tree quickly, seamonkey (because of enigmail) and enigmail are the
> only packages that declare a dep on GnuPG-1.4 explictly.

They do now? Was not the case two days ago (and yes, works just fine w/ gpg-2)

Re-opening please refer to bug 164523 for any questions as to why. Months have
gone by since I first reported this. Please next time let's be more polite to
each other, and do more to fix the in tree breakage sooner than later.

Thank you very much.

Closing this again, as the seahorse application should support gnupg-2.0 as
well now, and if it won't we make it work :)

I have taken this matter upstream.

"Seahorse requires an install of GPG 1.x"

http://www.gnome.org/projects/seahorse/RELEASE-NOTES-STABLE.txt

Slotting is inevitable, it's been avoided for over 2 months now. Upstream has
researched it, and made a decision. All other distros provide both, both were
designed to work together. Please slot, provide both at the same time as
upstream gnupg intended. And end the madness.

Since it's quite obvious this not being followed by either upstream here are
some links for further information. I am currently following the seahorse-devel
list. Their public archives are borked.

Here is a seahorse dev emailing gnupg devel list about gpgme and gnupg2.
http://marc.theaimsgroup.com/?l=gnupg-devel&m=117322943507164&w=2

After upstream assume there were no issues, issues were reported and confirmed.
http://marc.theaimsgroup.com/?l=gnupg-devel&m=117338885100661&w=2

So it's not just seahorse, and it's not looking like either will be modified
for gnupg2. Seahorse upstream has decided to explicitly require gnupg-1.x.

Ugh, someone fix the seahorse nonsense already instead of this completely
unproductive noise... Honestly, go use something else if upstream is unable to
fix it properly, don't really care.

jacub: Thanks, I am closing this again.

wltjr: We won't slot gnupg only because seahorse, please don't open this again
for this reason. gpgme works OK as far as I can see, I use it with kmail. If
you can produce somekind of scenario where it does not work, I will be happy to
work on this as well.

Just for the record...

$ pquery --raw --revdep=app-crypt/seahorse
$

Nothing depends on this... so, really go use something else if upstream refuses
to do anything about this, slotting stuff and creating huge maintenance
overhead because one package is retarded doesn't make sense.

ethelle user99 # emerge -NuvDp world

These are the packages that would be merged, in order:

Calculating world dependencies... done!
[ebuild     U ] sys-fs/sysfsutils-2.1.0 [1.3.0-r1] 771 kB
[ebuild     U ] sys-fs/reiserfsprogs-3.6.19-r2 [3.6.19-r1] 398 kB
[ebuild     U ] sys-devel/gdb-6.7.1 [6.6-r2] USE="nls -test -vanilla" 14,741 kB
[ebuild     U ] dev-libs/libassuan-1.0.2-r1 [0.6.10] 270 kB
[ebuild     U ] dev-util/dialog-1.1.20071028 [1.1.20070930] USE="examples nls
unicode" 362 kB
[ebuild     U ] media-libs/giflib-4.1.6 [4.1.4] USE="X -rle" 495 kB
[ebuild     U ] x11-apps/mesa-progs-7.0.1 [6.5.2] 4,575 kB
[ebuild   R   ] dev-java/sun-jre-bin-1.6.0.03  USE="X alsa nsplugin -odbc%" 0
kB
[ebuild     U ] x11-misc/xkeyboard-config-1.1 [0.9] 529 kB
[ebuild     U ] x11-libs/libXpm-3.5.7 [3.5.6] USE="-debug" 350 kB
[ebuild     U ] x11-apps/xwininfo-1.0.3 [1.0.2] USE="-debug" 97 kB
[ebuild     U ] media-libs/imlib-1.9.15-r2 [1.9.15-r1] USE="-doc -gtk" 668 kB
[ebuild   R   ] x11-proto/fontcacheproto-0.1.2  USE="(-debug%)" 38 kB
[ebuild  N    ] sys-auth/consolekit-0.2.3  USE="pam -debug" 458 kB
[ebuild     U ] x11-apps/xrdb-1.0.4 [1.0.3] USE="-debug" 99 kB
[ebuild     U ] x11-apps/xmodmap-1.0.3 [1.0.2] USE="-debug" 101 kB
[ebuild     U ] x11-proto/xf86dgaproto-2.0.3 [2.0.2] 43 kB
[ebuild     U ] x11-apps/xset-1.0.3 [1.0.2] USE="-debug" 101 kB
[ebuild     U ] x11-apps/xsetroot-1.0.2 [1.0.1] USE="-debug" 87 kB
[ebuild     U ] x11-apps/xprop-1.0.3 [1.0.2] USE="-debug" 105 kB
[ebuild  N    ] app-crypt/pinentry-0.7.3  USE="caps ncurses qt3 -gtk" 408 kB
[ebuild  N    ] net-misc/curl-7.16.4  USE="ipv6 kerberos ldap ssl -ares -gnutls
-idn -nss -test" 1,630 kB
[ebuild     U ] x11-libs/libXaw-1.0.4 [1.0.3] USE="-debug -xprint" 506 kB
[ebuild     U ] x11-libs/libXfont-1.3.1 [1.3.0] USE="ipv6 -debug" 552 kB
[ebuild     U ] x11-libs/libXxf86dga-1.0.2 [1.0.1] USE="-debug" 213 kB
[ebuild     U ] app-crypt/gnupg-2.0.7 [1.4.7-r1] USE="bzip2 ldap nls -doc%
-openct% -pcsc-lite% (-selinux) -smartcard (-bindist%) (-curl%) (-ecc%)
(-idea%) (-readline%*) (-static%) (-usb%) (-zlib%*)" LINGUAS="(-ru%)" 3,526 kB
[ebuild     U ] x11-apps/xmessage-1.0.2 [1.0.1] USE="-debug -xprint" 93 kB
[ebuild     U ] x11-apps/xclock-1.0.3 [1.0.2] USE="-debug -xprint" 112 kB
[ebuild     U ] x11-apps/xinit-1.0.5-r1 [1.0.4] USE="hal%* pam%* -debug
-minimal" 105 kB
[ebuild     U ] x11-drivers/xf86-input-mouse-1.2.3 [1.2.2] USE="-debug" 267 kB
[blocks B     ] <=app-crypt/gnupg-2.0.1 (is blocking app-crypt/gnupg-2.0.7)

Total: 30 packages (25 upgrades, 3 new, 2 reinstalls, 1 block), Size of
downloads: 31,680 kB
ethelle user99 #      

Ok I am blocked and what's more there is no   
gnupg-2.0.1 on the system. I need to unmerge  what?                             

emerge -C \<=app-crypt/gnupg-2.0.1; please read the message that portage
provides and that you snipped from the output; there's no support forum here.

unfortunately, only =gnupg-1.4* can be compiled statically.
so, what's your solution when a user requires a static
gpg (e.g. for encrypted root initramfs with cryptsetup/luks)
but also gnome (that depends on seahorse which depends on
=gpgme-1* which depends on >gnupg-1.9*)?

wschlich: I just forward ported the ebuild changes for USE=static, they work
too, decodes/encodes my testcases fine.

(In reply to comment #28)
> wschlich: I just forward ported the ebuild changes for USE=static, they work
> too, decodes/encodes my testcases fine.

Thanks mate, you made my day! :)

Note: smartcard does not work with static, and I remember something else...

I want to use gpg in an initramfs pre-boot environment, but this is very
difficult with gpg-2. gpg-1 works well enough, and is recommended by upstream:

"Note that this version is from the GnuPG-1 series and thus smaller
than those from the GnuPG-2 series, easier to build and also better
portable.  In contrast to GnuPG-2 (e.g version 2.0.8) it comes with no
support for S/MIME or other tools useful for desktop environments.
Fortunately you may install both versions alongside on the same system
without any conflict."
http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000266.h

Please slot these. They're intended to be installable together on the same
system, and providing different behavior than what upstream suggests in this
instance seems silly. Currently, I have to uninstall 2, install 1, copy the
binary, and then re-install 2.