Hello, For some unknown reason, the current GnuPG stable ebuild, v2.0.30 has been removed from the tree. In its place, v2.0.28 remains but cannot be merged (on downgrade) due to a missing gnupg-2.0.17-gpgsm-gencert.patch. [ebuild UD ] app-crypt/gnupg-2.0.28::gentoo [2.0.30::gentoo] USE="bzip2 -doc -ldap mta nls readline (-selinux) -smartcard -static tools usb" Kindly return v2.0.30 to the tree, keyworded or stable at least until it is no longer the recognized stable GnuPG package upstream. Best Regards, -Chicago
(In reply to Chicago from comment #0) > Hello, > > For some unknown reason, the current GnuPG stable ebuild, v2.0.30 has > been removed from the tree. In its place, v2.0.28 remains but cannot be > merged (on downgrade) due to a missing gnupg-2.0.17-gpgsm-gencert.patch. > > [ebuild UD ] app-crypt/gnupg-2.0.28::gentoo [2.0.30::gentoo] USE="bzip2 > -doc -ldap mta nls readline (-selinux) -smartcard -static tools usb" > > Kindly return v2.0.30 to the tree, keyworded or stable at least until it > is no longer the recognized stable GnuPG package upstream. FWIW, app-crypt/gnupg-2.0.30 was never marked stable in Gentoo. The current max stable on most arches is 2.1.15 wrt bug 552936. However that patch for 2.0.28 should be returned until that version is ready to be removed.
(In reply to Brian Evans from comment #1) > (In reply to Chicago from comment #0) > > Hello, > > > > For some unknown reason, the current GnuPG stable ebuild, v2.0.30 has > > been removed from the tree. In its place, v2.0.28 remains but cannot be > > merged (on downgrade) due to a missing gnupg-2.0.17-gpgsm-gencert.patch. > > > > [ebuild UD ] app-crypt/gnupg-2.0.28::gentoo [2.0.30::gentoo] USE="bzip2 > > -doc -ldap mta nls readline (-selinux) -smartcard -static tools usb" > > > > Kindly return v2.0.30 to the tree, keyworded or stable at least until it > > is no longer the recognized stable GnuPG package upstream. > > FWIW, app-crypt/gnupg-2.0.30 was never marked stable in Gentoo. He is referring to upstream that seems to confuse some users with the "stable" vs "modern" distinction of 2.0 and 2.1, not gentoo stable keywords. GnuPG is on its way out of Gentoo in bug 606604 > > The current max stable on most arches is 2.1.15 wrt bug 552936. Yes, waiting for a few more before completing 2.0 removal > > However that patch for 2.0.28 should be returned until that version is ready > to be removed. Indeed, will fix that
commit 1b8602a8659f24d7f2fd463d9fd08a7f4c606fc1 Author: Kristian Fiskerstrand <k_f@gentoo.org> Date: Tue Jan 24 18:42:54 2017 +0100 app-crypt/gnupg: Restore missing patch for gnupg 2.0 branch Package-Manager: Portage-2.3.3, Repoman-2.3.1
(In reply to Kristian Fiskerstrand from comment #2) > (In reply to Brian Evans from comment #1) > > (In reply to Chicago from comment #0) > > > Hello, > > > > > > For some unknown reason, the current GnuPG stable ebuild, v2.0.30 has > > > been removed from the tree. In its place, v2.0.28 remains but cannot be > > > merged (on downgrade) due to a missing gnupg-2.0.17-gpgsm-gencert.patch. > > > > > > [ebuild UD ] app-crypt/gnupg-2.0.28::gentoo [2.0.30::gentoo] USE="bzip2 > > > -doc -ldap mta nls readline (-selinux) -smartcard -static tools usb" > > > > > > Kindly return v2.0.30 to the tree, keyworded or stable at least until it > > > is no longer the recognized stable GnuPG package upstream. > > > > FWIW, app-crypt/gnupg-2.0.30 was never marked stable in Gentoo. > > He is referring to upstream that seems to confuse some users with the > "stable" vs "modern" distinction of 2.0 and 2.1, not gentoo stable keywords. > > GnuPG is on its way out of Gentoo in bug 606604 this was of course 2.0...
Hello, Why would v2.0.30 not be stabilized when it is the most current upstream stable GnuPG package and instead be removed from the tree when it has otherwise been available as a keyworded ebuild? Best Regards, -Chicago
(In reply to Chicago from comment #5) > Hello, > > Why would v2.0.30 not be stabilized when it is the most current upstream > stable GnuPG package and instead be removed from the tree when it has > otherwise been available as a keyworded ebuild? > > Best Regards, > -Chicago that is a separate question, it was removed because all testing packages in 2.0 branch were cleaned up, 2.0.28 will be removed once it is determined whether the remaining arches in bug 552936 determine whether to focus on 1.4 or 2.1 forwards (they likely don't need the 2.x features, but up to them)
Hello Kristian, Your statement in https://bugs.gentoo.org/show_bug.cgi?id=552936#c8, "GnuPG 2.0 is EOL 2017" is factually accurate but rather not specifically helpful to the spirit of this bug's intent to rectify the state of the stable GnuPG package branch in Gentoo. This branch will reach end-of-life on 2017-12-31, per the homepage. https://www.gnupg.org/ Thus, still for an unknown reason, critical tools used by gentoolkit, enigmail, git and other legacy tools are quite happy with the remaining 11 calendar months before EOL. Forcing a choice on users to accept an outdated version of a vital security package invokes the following section from the handbook. "It is very important that everyone understands that choices are what makes Gentoo run. We try not to force users into anything they do not like. If anyone believes otherwise, please bug report it." https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/About As well as the statement from the Complete Handbook in the Wiki, "After all, the user knows best what he needs and what not." https://wiki.gentoo.org/wiki/Complete_Handbook/Making_a_choice Does bug #552936 merit forcing users to use the outdated v2.0.28 release from the stable GnuPG 2.0 branch? Kindly return v2.0.30 to the tree, keyworded or preferably request stabilization at least until end-of-life on 2017-12-31. Best Regards, -Chicago
I meant to say genkernel rather then gentoolkit above -- as genkernel is employing gpg for use with LUKS.
(In reply to Chicago from comment #7) > Hello Kristian, > > Your statement in https://bugs.gentoo.org/show_bug.cgi?id=552936#c8, > "GnuPG 2.0 is EOL 2017" is factually accurate but rather not specifically > helpful to the spirit of this bug's intent to rectify the state of the > stable GnuPG package branch in Gentoo. > > This branch will reach end-of-life on 2017-12-31, per the homepage. > https://www.gnupg.org/ > > Thus, still for an unknown reason, critical tools used by gentoolkit, > enigmail, git and other legacy tools are quite happy with the remaining 11 > calendar months before EOL. > > Forcing a choice on users to accept an outdated version of a vital > security package invokes the following section from the handbook. There are no outdated versions involved here, both 1.4 and 2.1 are actively maintained, there is no reason to carry 3 concurrent branches in Gentoo now that 2.1 is stable. > > "It is very important that everyone understands that choices are what > makes Gentoo run. We try not to force users into anything they do not like. > If anyone believes otherwise, please bug report it." > > https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/About > > As well as the statement from the Complete Handbook in the Wiki, "After > all, the user knows best what he needs and what not." > > https://wiki.gentoo.org/wiki/Complete_Handbook/Making_a_choice > > > Does bug #552936 merit forcing users to use the outdated v2.0.28 release > from the stable GnuPG 2.0 branch? Current stable is 2.1.15 > > > Kindly return v2.0.30 to the tree, keyworded or preferably request > stabilization at least until end-of-life on 2017-12-31. 2.0 will be gone c.f previous comment, however you can of course always use a local overlay
(In reply to Chicago from comment #8) > I meant to say genkernel rather then gentoolkit above -- as genkernel is > employing gpg for use with LUKS. Makes absolutely no sense for that to prefer 2.0 over 1.4
(In reply to Kristian Fiskerstrand from comment #10) > (In reply to Chicago from comment #8) > > I meant to say genkernel rather then gentoolkit above -- as genkernel is > > employing gpg for use with LUKS. > > Makes absolutely no sense for that to prefer 2.0 over 1.4 Yes, what I was about to write. genkernel should use gnupg-1.4 for initramfs.
(In reply to Alon Bar-Lev from comment #11) > (In reply to Kristian Fiskerstrand from comment #10) > > (In reply to Chicago from comment #8) > > > I meant to say genkernel rather then gentoolkit above -- as genkernel is > > > employing gpg for use with LUKS. > > > > Makes absolutely no sense for that to prefer 2.0 over 1.4 > > Yes, what I was about to write. > genkernel should use gnupg-1.4 for initramfs. It actually is[1] [1] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-kernel/genkernel/genkernel-3.5.0.8.ebuild#n17
Hello, Yes, you're right about v1.4 with genkernel initramfs. You are wrong calling v2.1.15 current stable because it is not. v2.1.15 is a latent version of the GnuPG modern package, released 2016-08-18 where many bugs and regressions have since been fixed. Users prefer the canonical GnuPG stable package because there is a slower release cycle, fewer bugs and regressions along with a longer history of peer reviewed code. To compare some apples to apples, we do not find dev-libs/openssl:0 v1.0.2g anywhere in the tree today. Since its release on 2016-03-01, plenty of work has been done as can be seen here. https://www.openssl.org/news/openssl-1.0.2-notes.html We only find the upstream latest version of this peer reviewed code, v1.0.2j. Hence, one would expect to find the upstream latest version of GnuPG classic, GnuPG stable and GnuPG modern in the tree if *any* version is being offered whatsoever. It may be your will to carry only GnuPG classic and GnuPG modern in the Gentoo tree in the future, but you are forcing users to accept this decision and are persistent in claiming app-crypt/gnupg-2.15 is current stable in full knowledge of the upstream nomenclature. Kindly return v2.0.30 to the Gentoo tree until end-of-life on 2017-12-31. Best Regards, -Chicago
@Chicago: please specify what feature exactly do you missing in gnupg-2.1, please stop bureaucracy arguments.
(In reply to Chicago from comment #13) > Hello, > > Yes, you're right about v1.4 with genkernel initramfs. > > You are wrong calling v2.1.15 current stable because it is not. v2.1.15 > is a latent version of the GnuPG modern package, released 2016-08-18 where > many bugs and regressions have since been fixed. I've referred you to it before, but as per announcement: - GnuPG "modern" (2.1) comes with the latest features and is suggested for most users. This announcement is about this branch. gnupg 2.1 is also offered as only implementation in debian sid, and we're working along with other package maintainers to also switch that. There are no reasons for 2.0 over 2.1 at this point. Gnupg 2.1.18 will be stabilized in Gentoo in due course, there are no major regressions since 2.1.15, if you want the latest available use testing which already has 2.1.18.
