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

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

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

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

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. > --- >

[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

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

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

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

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

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

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

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.

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]

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

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

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. > >

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