Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat
On Tue, May 2, 2017 at 1:08 PM, Michał Górny wrote: > On wto, 2017-05-02 at 12:11 -0700, Zac Medico wrote: > > On Tue, May 2, 2017 at 12:01 PM, Michał Górny wrote: > > > > > On wto, 2017-05-02 at 11:49 -0700, Zac Medico wrote: > > > > Add forward compatibility up to python3.9. It's helpful to allow some > > > > flexibility in ebuild PYTHON_COMPAT settings, for third-party > > > > repositories that may be used with multiple snapshots of the gentoo > > > > repository. > > > > --- > > > > eclass/python-utils-r1.eclass | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1. > > > > > > eclass > > > > index 66a359e..997a994 100644 > > > > --- a/eclass/python-utils-r1.eclass > > > > +++ b/eclass/python-utils-r1.eclass > > > > @@ -70,7 +70,7 @@ _python_impl_supported() { > > > > python2_7|python3_[456]|jython2_7) > > > > return 0 > > > > ;; > > > > - pypy1_[89]|pypy2_0|python2_[56]|python3_[123]) > > > > + pypy1_[89]|pypy2_0|python2_[56]|python3_[123789]) > > > > return 1 > > > > ;; > > > > pypy|pypy3) > > > > > > Sounds like a very bad idea. How can you even think of adding > > > an implementation if you don't know what the eclass API for it would > be? > > > > > > > For my use case, we're adding python3_6 to PYTHON_COMPAT, and still using > > those ebuilds with older snapshots of the gentoo repository from a few > > months back (as well as newer snapshots). So, there's really no danger in > > my case. > > > > With my suggested change, the eclass doesn't make any API guarantees. > > Where's the harm? > > Unless I'm missing something, this is going to cause the eclass to > accept (and ignore) accidental use of python3_7. It's confusing, to say > the least. > > If you really want to do weird stuff, you're on your own. Okay, I've sent a new patch that adds a PYTHON_IMPLS_NO_STRICT variable. -- Thanks, Zac
[gentoo-dev] [PATCH] python-utils-r1.eclass: support PYTHON_IMPLS_NO_STRICT variable
This is intended to be set by the user when using ebuilds that may have unknown implementations in PYTHON_COMPAT. The assumption is that the ebuilds are intended to be used within multiple contexts which can involve revisions of this eclass that support different python implementations. --- eclass/python-utils-r1.eclass | 16 1 file changed, 16 insertions(+) diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index 66a359e..1846da3 100644 --- a/eclass/python-utils-r1.eclass +++ b/eclass/python-utils-r1.eclass @@ -47,6 +47,21 @@ _PYTHON_ALL_IMPLS=( ) readonly _PYTHON_ALL_IMPLS +# @ECLASS-VARIABLE: PYTHON_IMPLS_NO_STRICT +# @DESCRIPTION: +# Tolerate unknown implementations in PYTHON_COMPAT. +# +# This is intended to be set by the user when using ebuilds that may +# have unknown implementations in PYTHON_COMPAT. The assumption is +# that the ebuilds are intended to be used within multiple contexts +# which can involve revisions of this eclass that support different +# python implementations. +# +# Example: +# @CODE +# PYTHON_IMPLS_NO_STRICT=1 +# @CODE + # @FUNCTION: _python_impl_supported # @USAGE: # @INTERNAL @@ -79,6 +94,7 @@ _python_impl_supported() { fi ;; *) + [[ -n ${PYTHON_IMPLS_NO_STRICT} ]] && return 1 die "Invalid implementation in PYTHON_COMPAT: ${impl}" esac } -- 2.10.2
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat
On wto, 2017-05-02 at 12:11 -0700, Zac Medico wrote: > On Tue, May 2, 2017 at 12:01 PM, Michał Górny wrote: > > > On wto, 2017-05-02 at 11:49 -0700, Zac Medico wrote: > > > Add forward compatibility up to python3.9. It's helpful to allow some > > > flexibility in ebuild PYTHON_COMPAT settings, for third-party > > > repositories that may be used with multiple snapshots of the gentoo > > > repository. > > > --- > > > eclass/python-utils-r1.eclass | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1. > > > > eclass > > > index 66a359e..997a994 100644 > > > --- a/eclass/python-utils-r1.eclass > > > +++ b/eclass/python-utils-r1.eclass > > > @@ -70,7 +70,7 @@ _python_impl_supported() { > > > python2_7|python3_[456]|jython2_7) > > > return 0 > > > ;; > > > - pypy1_[89]|pypy2_0|python2_[56]|python3_[123]) > > > + pypy1_[89]|pypy2_0|python2_[56]|python3_[123789]) > > > return 1 > > > ;; > > > pypy|pypy3) > > > > Sounds like a very bad idea. How can you even think of adding > > an implementation if you don't know what the eclass API for it would be? > > > > For my use case, we're adding python3_6 to PYTHON_COMPAT, and still using > those ebuilds with older snapshots of the gentoo repository from a few > months back (as well as newer snapshots). So, there's really no danger in > my case. > > With my suggested change, the eclass doesn't make any API guarantees. > Where's the harm? Unless I'm missing something, this is going to cause the eclass to accept (and ignore) accidental use of python3_7. It's confusing, to say the least. If you really want to do weird stuff, you're on your own. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat
On Tue, May 2, 2017 at 12:01 PM, Michał Górny wrote: > On wto, 2017-05-02 at 11:49 -0700, Zac Medico wrote: > > Add forward compatibility up to python3.9. It's helpful to allow some > > flexibility in ebuild PYTHON_COMPAT settings, for third-party > > repositories that may be used with multiple snapshots of the gentoo > > repository. > > --- > > eclass/python-utils-r1.eclass | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1. > eclass > > index 66a359e..997a994 100644 > > --- a/eclass/python-utils-r1.eclass > > +++ b/eclass/python-utils-r1.eclass > > @@ -70,7 +70,7 @@ _python_impl_supported() { > > python2_7|python3_[456]|jython2_7) > > return 0 > > ;; > > - pypy1_[89]|pypy2_0|python2_[56]|python3_[123]) > > + pypy1_[89]|pypy2_0|python2_[56]|python3_[123789]) > > return 1 > > ;; > > pypy|pypy3) > > Sounds like a very bad idea. How can you even think of adding > an implementation if you don't know what the eclass API for it would be? > For my use case, we're adding python3_6 to PYTHON_COMPAT, and still using those ebuilds with older snapshots of the gentoo repository from a few months back (as well as newer snapshots). So, there's really no danger in my case. With my suggested change, the eclass doesn't make any API guarantees. Where's the harm? -- Thanks, Zac
Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat
On wto, 2017-05-02 at 11:49 -0700, Zac Medico wrote: > Add forward compatibility up to python3.9. It's helpful to allow some > flexibility in ebuild PYTHON_COMPAT settings, for third-party > repositories that may be used with multiple snapshots of the gentoo > repository. > --- > eclass/python-utils-r1.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass > index 66a359e..997a994 100644 > --- a/eclass/python-utils-r1.eclass > +++ b/eclass/python-utils-r1.eclass > @@ -70,7 +70,7 @@ _python_impl_supported() { > python2_7|python3_[456]|jython2_7) > return 0 > ;; > - pypy1_[89]|pypy2_0|python2_[56]|python3_[123]) > + pypy1_[89]|pypy2_0|python2_[56]|python3_[123789]) > return 1 > ;; > pypy|pypy3) Sounds like a very bad idea. How can you even think of adding an implementation if you don't know what the eclass API for it would be? -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat
Add forward compatibility up to python3.9. It's helpful to allow some flexibility in ebuild PYTHON_COMPAT settings, for third-party repositories that may be used with multiple snapshots of the gentoo repository. --- eclass/python-utils-r1.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/python-utils-r1.eclass b/eclass/python-utils-r1.eclass index 66a359e..997a994 100644 --- a/eclass/python-utils-r1.eclass +++ b/eclass/python-utils-r1.eclass @@ -70,7 +70,7 @@ _python_impl_supported() { python2_7|python3_[456]|jython2_7) return 0 ;; - pypy1_[89]|pypy2_0|python2_[56]|python3_[123]) + pypy1_[89]|pypy2_0|python2_[56]|python3_[123789]) return 1 ;; pypy|pypy3) -- 2.10.2
Re: [gentoo-dev] Bugzilla package list editing
Am Dienstag, 2. Mai 2017, 18:27:58 CEST schrieb Andreas K. Huettel: > > The much better alternative would be > * Don't do any cosmetic changes. They are pointless for a bot-evaluated > field. * If you need additional keywords or want to drop something, leave > one sentence on the bug with request and reason, and let maintainers sort > out the package list field... Or alternatively just un-cc your arch with "xxx is skipping this". -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Bugzilla package list editing
Am Dienstag, 2. Mai 2017, 13:05:38 CEST schrieb Chí-Thanh Christopher Nguyễn: > > Also very common is that he changes fully qualified package names (which > is the correct syntax per [1]) into fully qualified package atoms (which > is the legacy syntax). Bug 616260 is one such example. That's one thing. And it's super annoying since the bugzilla e-mails try to provide a diff, but the result is for longer package lists unreadable and not helpful. Also, in some cases, additionally keywords were added and removed from the list without any further comment. Taking this possibility into account, one would have to check any BZ mail with a lot of attention. The much better alternative would be * Don't do any cosmetic changes. They are pointless for a bot-evaluated field. * If you need additional keywords or want to drop something, leave one sentence on the bug with request and reason, and let maintainers sort out the package list field... -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/3] tmpfiles.eclass: Support using on non-Linux systems
On Tue, May 2, 2017 at 10:38 AM, William Hubbs wrote: > On Sun, Apr 30, 2017 at 09:06:53PM +0200, Michał Górny wrote: >> Fix the eclass code to remove the misguided Linux conditionals. >> The whole purpose of the eclass was to avoid having to implement >> fallback logic for systems not having service manager tmpfiles.d >> support. Making it conditional to Linux implied that for non-Linux >> systems (Prefix, FreeBSD) we would have to implement explicit fallback >> to create the necessary directories. >> >> While systemd (and therefore systemd-tmpfilesd) is indeed >> Linux-specific, the opentmpfiles implementation should be pretty >> portable and there is no reason to restrict it to Linux only, or to >> prevent using it on non-Linux OpenRC (and non-OpenRC) systems. > > Opentmpfiles can run right now on non-openrc systems, but it requires a > linux host; that is why the Linux conditionals are there. We currently support > selinux and even more specific linux code is coming with the btrfs > subvolume support. My Linux system does not support selinux. Other people have Linux systems which do not support btrfs. tmpfiles still works on such systems. What exactly breaks on non-Linux systems?
Re: [gentoo-dev] Bugzilla package list editing
Am Dienstag, 2. Mai 2017, 14:32:13 CEST schrieb Ulrich Mueller: > > On Tue, 2 May 2017, Chí-Thanh Christopher Nguyễn wrote: > > Also very common is that he changes fully qualified package names > > (which is the correct syntax per [1]) into fully qualified package > > atoms (which is the legacy syntax). Bug 616260 is one such example. > > > > [1] https://bugs.gentoo.org/page.cgi?id=fields.html > > Can't the stable-bot enforce the correct syntax? A little bird already mentioned to me that the stable bot ignores bugs filed by one particular developer, who insists to repeatedly fill in invalid data and can't be taught otherwise. (And that's just about the maximum level of "enforcement" possible here. Should be effective on the long run though.) -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [PATCH 1/3] tmpfiles.eclass: Support using on non-Linux systems
On wto, 2017-05-02 at 09:38 -0500, William Hubbs wrote: > On Sun, Apr 30, 2017 at 09:06:53PM +0200, Michał Górny wrote: > > Fix the eclass code to remove the misguided Linux conditionals. > > The whole purpose of the eclass was to avoid having to implement > > fallback logic for systems not having service manager tmpfiles.d > > support. Making it conditional to Linux implied that for non-Linux > > systems (Prefix, FreeBSD) we would have to implement explicit fallback > > to create the necessary directories. > > > > While systemd (and therefore systemd-tmpfilesd) is indeed > > Linux-specific, the opentmpfiles implementation should be pretty > > portable and there is no reason to restrict it to Linux only, or to > > prevent using it on non-Linux OpenRC (and non-OpenRC) systems. > > Opentmpfiles can run right now on non-openrc systems, but it requires a > linux host; that is why the Linux conditionals are there. We currently support > selinux and even more specific linux code is coming with the btrfs > subvolume support. It's funny because I've just got a confirmation that it works on FreeBSD. > The purpose of opentmpfiles is to provide a non-systemd program that > mirrors the behavior of systemd-tmpfiles so that Linux users do not have > to install systemd, but there are features that definitely would not > work on other hosts. We need a tool that works for everyone. Not excuses not to support Linux just because systemd does not. > Also, the tmpfiles.d standard doesn't allow tmpfiles to do things based > on operating systems, And what's the problem with installing tmpfiles.d files aligned to the operating system in question? After all, you don't tell everyone not to use OpenRC outside Linux just because someone might have put Linux- specific paths in the init.d file. > and the configuration search paths (particularly > /run/tmpfiles.d and the non-support of /lib/tmpfiles.d) are linux specific. > Does that hurt anyone? We're talking about Gentoo/FBSD and Gentoo Prefix, i.e. Gentoo-flavored systems which we have control over. If you really insist, I can ask our FBSD/Prefix teams to look through the code and make sure that it works across all interesting platforms. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [PATCH 1/3] tmpfiles.eclass: Support using on non-Linux systems
On Sun, Apr 30, 2017 at 09:06:53PM +0200, Michał Górny wrote: > Fix the eclass code to remove the misguided Linux conditionals. > The whole purpose of the eclass was to avoid having to implement > fallback logic for systems not having service manager tmpfiles.d > support. Making it conditional to Linux implied that for non-Linux > systems (Prefix, FreeBSD) we would have to implement explicit fallback > to create the necessary directories. > > While systemd (and therefore systemd-tmpfilesd) is indeed > Linux-specific, the opentmpfiles implementation should be pretty > portable and there is no reason to restrict it to Linux only, or to > prevent using it on non-Linux OpenRC (and non-OpenRC) systems. Opentmpfiles can run right now on non-openrc systems, but it requires a linux host; that is why the Linux conditionals are there. We currently support selinux and even more specific linux code is coming with the btrfs subvolume support. The purpose of opentmpfiles is to provide a non-systemd program that mirrors the behavior of systemd-tmpfiles so that Linux users do not have to install systemd, but there are features that definitely would not work on other hosts. Also, the tmpfiles.d standard doesn't allow tmpfiles to do things based on operating systems, and the configuration search paths (particularly /run/tmpfiles.d and the non-support of /lib/tmpfiles.d) are linux specific. William signature.asc Description: Digital signature
Re: [gentoo-dev] Bugzilla package list editing
Hi, On Tue, 2 May 2017 13:05:38 +0200 Chí-Thanh Christopher Nguyễn wrote: >Paweł Hajdan, Jr. schrieb: > Please stop editing package lists when you are not the maintainer and arches are already CCed. >>> +1 >>> >>> Please stop it. >>> And yes that's also true for arch team members. >>> >>> Package list is maintainer territory. >> Curious, what are the reasons and what changes people make that they >> shouldn't? >> >> I'm wondering if there's some solution to these issues (maybe better >> documentation, or an alternative way of accomplishing what these >> people try to do). > >As dilfridge pur jer in CC, I guess that some of jer's changes to bugs >were not welcomed by maintainers. > >One recent example of non-maintainer activity in the package list >field is bug 613104, where he just removed the entire package list >(and then marked the bug WONTFIX). >Also very common is that he changes fully qualified package names >(which is the correct syntax per [1]) into fully qualified package >atoms (which is the legacy syntax). Bug 616260 is one such example. I must admit that I did the same (changing full package names to full package atoms). IIRC when these package lists were introduced this was the only valid syntax and stable bot complained if it was not a package atom. >Best regards, >Chí-Thanh Christopher Nguyễn > >[1] https://bugs.gentoo.org/page.cgi?id=fields.html > Kind regards Lars -- Lars Wendler Gentoo package maintainer GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39 pgp4jLNV_asn2.pgp Description: Digitale Signatur von OpenPGP
Re: [gentoo-dev] Bugzilla package list editing
> On Tue, 2 May 2017, Chí-Thanh Christopher Nguyễn wrote: > Also very common is that he changes fully qualified package names > (which is the correct syntax per [1]) into fully qualified package > atoms (which is the legacy syntax). Bug 616260 is one such example. > [1] https://bugs.gentoo.org/page.cgi?id=fields.html Can't the stable-bot enforce the correct syntax? Ulrich pgpd8IdioSYPe.pgp Description: PGP signature
Re: [gentoo-dev] Bugzilla package list editing
Paweł Hajdan, Jr. schrieb: Please stop editing package lists when you are not the maintainer and arches are already CCed. +1 Please stop it. And yes that's also true for arch team members. Package list is maintainer territory. Curious, what are the reasons and what changes people make that they shouldn't? I'm wondering if there's some solution to these issues (maybe better documentation, or an alternative way of accomplishing what these people try to do). As dilfridge pur jer in CC, I guess that some of jer's changes to bugs were not welcomed by maintainers. One recent example of non-maintainer activity in the package list field is bug 613104, where he just removed the entire package list (and then marked the bug WONTFIX). Also very common is that he changes fully qualified package names (which is the correct syntax per [1]) into fully qualified package atoms (which is the legacy syntax). Bug 616260 is one such example. Best regards, Chí-Thanh Christopher Nguyễn [1] https://bugs.gentoo.org/page.cgi?id=fields.html
[gentoo-dev] packages up for grabs (from phajdan.jr, May 2017)
This is probably overdue. I'm not really maintaining the following packages, mostly because I no longer use them. I have dropped myself from metadata.xml . Feel free to grab. If you have questions about them, just email me. app-admin/logcheck (2 bugs) app-admin/syslog-summary (1 bug) app-misc/lockfile-progs media-plugins/gimp-lqr sci-mathematics/spin sys-apps/hardened-shadow (1 bug) For the following packages, I've removed myself from metadata.xml, but there are other maintainers/projects: dev-python/pyftpdlib (python) Thanks, Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Bugzilla package list editing
On 02/05/2017 02:31, Andreas K. Huettel wrote: > Am Sonntag, 30. April 2017, 12:29:46 CEST schrieb Mart Raudsepp: >> Please stop editing package lists when you are not the maintainer and >> arches are already CCed. > +1 > > Please stop it. > And yes that's also true for arch team members. > > Package list is maintainer territory. Curious, what are the reasons and what changes people make that they shouldn't? I'm wondering if there's some solution to these issues (maybe better documentation, or an alternative way of accomplishing what these people try to do). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs
On Fri, Apr 28, 2017 at 11:02:40PM +0200, Manuel Rüger wrote: > dev-tex/biblatex > dev-tex/biblatex-apa > dev-tex/biber I would volunteer to proxy-maintain these. I already proxy-maintain a few packages and would go through the same contact (xmw). signature.asc Description: Digital signature