Summary: | app-portage/layman dev-python/pyGPG rekeywording | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Brian Dolbec <dolsen> |
Component: | Keywording | Assignee: | Layman Overlay Manager project <layman> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | m68k, mgorny, sh+disabled, tools-portage, twitch153 |
Priority: | Normal | Keywords: | KEYWORDREQ |
Version: | unspecified | Flags: | stable-bot:
sanity-check-
|
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: |
=dev-python/pyGPG-0.2 m68k sh
=app-portage/layman-2.4.2-r1 m68k sh
=app-portage/g-sorcery-0.2.1-r1 m68k sh
|
Runtime testing required: | --- |
Bug Depends on: | 557030 | ||
Bug Blocks: | 563114 |
Description
Brian Dolbec (RETIRED)
2015-02-08 18:59:06 UTC
(In reply to Brian Dolbec from comment #0) > My recommended use.mask > > # Brian Dolbec <dolsen@gentoo.org> (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? Doh! missed the gpg flag on there. # Brian Dolbec <dolsen@gentoo.org> (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. Why does the Summary tell arch teams to mask a beneficial feature? I simply don't get why it would request that. 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. (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? Marked ~hppa. Added ~mips, thanks! ~s390 added Adding mips@ back, please either keyword dev-python/pyGPG or mask "gpg" USE flag on app-portage/layman in your profile 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! (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. Marked ~ppc64. keyworded for ppc. Tests fail on alpha, see bug 557030 dev-python/pyGPG-0.2 is ~arm64, removing from CC added ~alpha /me WTFs ago stabilized these on ia64/sparc in bug 603108 An automated check of this bug failed - the following atom is unknown: app-portage/layman-2.4.2 Please verify the atom list. 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(-)]']
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(-)]']
*-fbsd is gone. |