Bug 539366 – app-portage/layman dev-python/pyGPG rekeywording

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description Brian Dolbec (RETIRED) 2015-02-08 18:59:06 UTC]

My recommended use.mask 

# Brian Dolbec <[e-mail]> (08 Feb 2015)
# missing keyword on dev-python/pyGPG
# not testable in layman yet
# waiting for the repositories.xml list to be signed
=app-portage-layman-2.3.0


The gentoo-keys project is making headway and hopefully soon, will be getting things like the repositories.xml list signed automatically.  Currently the list is updatable by all devs, but will likely be restricted to the overlays team soon.  Once that happens, the list should be signed as part of it's modification.

Reproducible: Always

[Comment 1 Mike Gilbert 2015-02-08 19:08:03 UTC]

(In reply to Brian Dolbec from comment #0)
> My recommended use.mask 
> 
> # Brian Dolbec <[e-mail]> (08 Feb 2015)
> # missing keyword on dev-python/pyGPG
> # not testable in layman yet
> # waiting for the repositories.xml list to be signed
> =app-portage-layman-2.3.0

This seems to be a package.mask entry, not use.mask.

Also, which arch teams need to look at this bug?

[Comment 2 Brian Dolbec (RETIRED) 2015-02-08 19:24:01 UTC]

Doh!  missed the gpg flag on there.

# Brian Dolbec <[e-mail]> (08 Feb 2015)
# missing keyword on dev-python/pyGPG
# not testable in layman yet
# waiting for the repositories.xml list to be signed
=app-portage-layman-2.3.0 gpg


keywords list from 2.2.0-r7:

"~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86 ~ppc-aix ~x86-fbsd ~hppa-hpux ~ia64-hpux ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos ~sparc-solaris ~x64-solaris ~x86-solaris"

Currently dev-python/pyGPG has "~amd64 ~arm ~x86" keywords.

The easiest testing now for pyGPG can be done using the new app-crypt/gkeys package.  I will be opening a keywording bug for gkeys with it's next release.

[Comment 3 Jeroen Roovers (RETIRED) 2015-02-08 21:38:24 UTC]

Why does the Summary tell arch teams to mask a beneficial feature? I simply don't get why it would request that.

[Comment 4 Brian Dolbec (RETIRED) 2015-02-09 00:28:52 UTC]

Currently there is no way for the arch teams to test the gpg feature which uses pyGPG for the task.  The feature will only become useful once the overlays team starts signing the repositories.xml list.

I will put up a test overlay list with signature that arch testers can use to test the feature, complete with instructions how to perform the test.  Then they will be able to correctly test and keyword dev-python/pyGPG.

[Comment 5 Jeroen Roovers (RETIRED) 2015-02-09 11:06:14 UTC]

(In reply to Brian Dolbec from comment #4)
> Currently there is no way for the arch teams to test the gpg feature which
> uses pyGPG for the task.  The feature will only become useful once the
> overlays team starts signing the repositories.xml list.

That is no problem right now. And when you do start seeing architecture related problems with this, you're bound to be more likely to seem them in unmasked testing than with no keywording and a use.mask in place. Which is the time when you can fix any issues that may arise and then start calling for stabilisation.

> I will put up a test overlay list with signature that arch testers can use
> to test the feature, complete with instructions how to perform the test. 
> Then they will be able to correctly test and keyword dev-python/pyGPG.

Wouldn't that new feature be subject to run-time configuration anyway? So that if it does fail (and that issue is the subject of another bug report), you should be able to simply disable it without changing USE flags?

[Comment 6 Jeroen Roovers (RETIRED) 2015-02-11 09:13:17 UTC]

Marked ~hppa.

[Comment 7 Joshua Kinard 2015-02-18 13:03:23 UTC]

Added ~mips, thanks!

[Comment 8 Sergey Popov (RETIRED) 2015-02-18 13:38:37 UTC]

~s390 added

[Comment 9 Sergey Popov (RETIRED) 2015-02-18 14:05:18 UTC]

Adding mips@ back, please either keyword dev-python/pyGPG or mask "gpg" USE flag on app-portage/layman in your profile

[Comment 10 Joshua Kinard 2015-02-18 15:19:02 UTC]

Test-compiled pyGPG-0.1, and that went in fine.  Added ~mips to pyGPG and that should fix this for us.  Let us know if we missed anything!

[Comment 11 Anthony Basile 2015-02-18 21:11:57 UTC]

(In reply to Joshua Kinard from comment #10)
> Test-compiled pyGPG-0.1, and that went in fine.  Added ~mips to pyGPG and
> that should fix this for us.  Let us know if we missed anything!

hey, i was just workign on that :)  anyhow, its working fine on the lemote so double testing from mips team.

[Comment 12 Jeroen Roovers (RETIRED) 2015-05-02 09:03:52 UTC]

Marked ~ppc64.

[Comment 13 Anthony Basile 2015-05-07 16:04:11 UTC]

keyworded for ppc.

[Comment 14 Tobias Klausmann (RETIRED) 2015-08-08 11:46:03 UTC]

Tests fail on alpha, see bug 557030

[Comment 15 Michael Weber (RETIRED) 2017-03-01 12:29:29 UTC]

dev-python/pyGPG-0.2 is ~arm64, removing from CC

[Comment 16 Matt Turner 2017-03-30 00:29:17 UTC]

added ~alpha

[Comment 17 Matt Turner 2017-03-30 00:31:09 UTC]

/me WTFs

ago stabilized these on ia64/sparc in bug 603108

[Comment 18 Stabilization helper bot 2018-04-26 15:00:17 UTC]

An automated check of this bug failed - the following atom is unknown:

app-portage/layman-2.4.2

Please verify the atom list.

[Comment 19 Stabilization helper bot 2018-04-26 16:00:38 UTC]

An automated check of this bug failed - repoman reported dependency errors: 

> dependency.bad app-portage/layman/layman-2.4.2-r1.ebuild: RDEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/11.1) ['app-portage/g-sorcery', '>=dev-python/ssl-fetch-0.4[python_targets_pypy(-)?,python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,-python_single_target_pypy(-),-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]']

[Comment 20 Stabilization helper bot 2019-01-15 18:00:43 UTC]

An automated check of this bug failed - repoman reported dependency errors: 

> dependency.bad dev-python/ssl-fetch/ssl-fetch-0.4.ebuild: RDEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/11.1) ['dev-python/ndg-httpsclient[python_targets_python2_7]']
> dependency.bad app-portage/g-sorcery/g-sorcery-0.2.1-r1.ebuild: DEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/11.1) ['dev-python/pymongo[python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]']
> dependency.bad app-portage/g-sorcery/g-sorcery-0.2.1-r1.ebuild: RDEPEND: ~amd64-fbsd(default/bsd/fbsd/amd64/11.1) ['dev-python/pymongo[python_targets_python2_7(-)?,python_targets_python3_4(-)?,python_targets_python3_5(-)?,python_targets_python3_6(-)?,-python_single_target_python2_7(-),-python_single_target_python3_4(-),-python_single_target_python3_5(-),-python_single_target_python3_6(-)]']

[Comment 21 Michał Górny 2019-10-11 17:30:27 UTC]

*-fbsd is gone.