Re: [gentoo-dev] [PATCH] python-utils-r1.eclass: _python_impl_supported, forward compat

[Zac Medico]

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

[Zac Medico]

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

[Michał Górny]

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

[Zac Medico]

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

[Michał Górny]

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

[Zac Medico]

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

[Andreas K. Huettel]

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

[Andreas K. Huettel]

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

[Mike Gilbert]

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

[Andreas K. Huettel]

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

[Michał Górny]

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

[William Hubbs]

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

[Lars Wendler]

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

[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?

Ulrich


pgpd8IdioSYPe.pgp
Description: PGP signature

Re: [gentoo-dev] Bugzilla package list editing

[Chí-Thanh Christopher Nguyễn]

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)

[Paweł Hajdan , Jr .]

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

[Paweł Hajdan , Jr .]

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

[Hendrik v. Raven]

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