Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

[Rémi Cardona]

Le jeudi 22 novembre 2012 à 20:59 +0100, Michał Górny a écrit :

> You could say it's an algo like this:
> 
> 1) if you want phase functions for distutils & all other automagic,
>use distutils-r1;
> 
> 2) if you don't want phase functions but want PYTHON_TARGETS and other
>metadata stuff, use python-r1;
> 
> 3) if you don't want phase functions nor metadata, just some random
>potentially useful functions, use python-utils-r1.


Please, pretty please: paste this blurb somewhere (near the top) in
*one* of the above three eclasses and modify the other 2 to point
developers to the former eclass.

Cheers,

Rémi

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/lyx: lyx-2.0.5.ebuild ChangeLog

[Duncan]

Patrick Lauer posted on Fri, 23 Nov 2012 12:45:56 +0800 as excerpted:

> On 11/20/12 21:57, Alexis Ballier wrote:
>> On Fri, 16 Nov 2012 09:10:51 + (UTC)
>> "Patrick Lauer (patrick)"  wrote:
>> 
>>> patrick 12/11/16 09:10:51
>>>
>>>   Modified: ChangeLog
>>>   Added:lyx-2.0.5.ebuild
>>>   Log:  Bump
>>>   
>> While the bump was fine, please read the damn metadata.xml when you
>> touch a package you're not used to. Pavel has been doing a very good
>> job in (proxy) maintaining lyx since years and you do not seem to have
>> contacted him before doing the bump, which is a bit disrespectful for
>> him IMHO.
> 
> I disagree. A fix is a fix, a bump is a bump, no ego involved.
> 
>> If you want to help in having things done quicker because I'm not
>> always responsive enough, then please do it correctly and ask Pavel to
>> CC you when he sends me instructions for lyx.
> I dislike this territorialism. Why add a single point of failure to
> package maintenance? (What if you or Pavel "disappear" for any reason?)

Reasonable points on both sides.

At minimum a note to the maintainers (both proxy and non-gentoo-dev) 
would have been nice.  A wait of say two (work) days minimum (a full 
week's probably reasonable on most packages) for a reply would have been 
a courtesy as well, given the maintainer may be aware of issues with the 
new version that need worked out.

OTOH, I get as antsy as anyone when I see a new version out, yet not in-
tree (or even in the testing overlay when there is one) even masked.[1]  
If there's no reply in a few days, then yes, I'd say go ahead and non-
maintainer-bump.

---
[1] I've bumped firefox to 17 here locally, as it's not even in the 
overlay yet, and 16.0.2 wasn't letting me in to my bank any longer, 
probably due to a rebuild needed. I figured I might as well try the new 
version since it's out instead of just rebuilding the old one only to 
have to build the new one in a day or two, but I had to bump locally and 
fix up one line on a gentoo patch to do it.  Yes, I'm antsy, but not 
complaining altho firefox is a high enough priority and high exposure app 
with security issues fixed, so much longer and I COULD be, but I'm just 
using it as an illustration here.  (IOW, FF is an app where I'd say 
closer to that two day minimum, even if for most apps I'd say a week.  
But of course it's also a complicated app, with gentoo often carrying a 
number of patches, so a bit of delay could be understandable... but I'd 
still like to see it in the mozilla overlay at least, even if it's not 
considered ready for the tree, even masked.  That's the reason I /have/ 
that overlay setup in layman, after all!)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/lyx: lyx-2.0.5.ebuild ChangeLog

[Matthew Thode]

On 11/22/2012 10:45 PM, Patrick Lauer wrote:
> On 11/20/12 21:57, Alexis Ballier wrote:
>> On Fri, 16 Nov 2012 09:10:51 + (UTC)
>> "Patrick Lauer (patrick)"  wrote:
>>
>>> patrick 12/11/16 09:10:51
>>>
>>>   Modified: ChangeLog
>>>   Added:lyx-2.0.5.ebuild
>>>   Log:
>>>   Bump
>>>   
>>
>>
>>
>> While the bump was fine, please read the damn metadata.xml when you
>> touch a package you're not used to. Pavel has been doing a very good
>> job in (proxy) maintaining lyx since years and you do not seem to have
>> contacted him before doing the bump, which is a bit disrespectful for
>> him IMHO.
> 
> I disagree. A fix is a fix, a bump is a bump, no ego involved.
> 
>> If you want to help in having things done quicker because I'm not
>> always responsive enough, then please do it correctly and ask Pavel to
>> CC you when he sends me instructions for lyx.
> I dislike this territorialism. Why add a single point of failure to
> package maintenance? (What if you or Pavel "disappear" for any reason?)
> 
> Have fun,
> 
> Patrick
> 
> 
Generally I think contacting the maintainer is nice, I typically set a
timeout (depending on severity) so that if they don't respond you do
what is needed.

-- 
-- Matthew Thode (prometheanfire)



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-office/lyx: lyx-2.0.5.ebuild ChangeLog

[Patrick Lauer]

On 11/20/12 21:57, Alexis Ballier wrote:
> On Fri, 16 Nov 2012 09:10:51 + (UTC)
> "Patrick Lauer (patrick)"  wrote:
> 
>> patrick 12/11/16 09:10:51
>>
>>   Modified: ChangeLog
>>   Added:lyx-2.0.5.ebuild
>>   Log:
>>   Bump
>>   
> 
> 
> 
> While the bump was fine, please read the damn metadata.xml when you
> touch a package you're not used to. Pavel has been doing a very good
> job in (proxy) maintaining lyx since years and you do not seem to have
> contacted him before doing the bump, which is a bit disrespectful for
> him IMHO.

I disagree. A fix is a fix, a bump is a bump, no ego involved.

> If you want to help in having things done quicker because I'm not
> always responsive enough, then please do it correctly and ask Pavel to
> CC you when he sends me instructions for lyx.
I dislike this territorialism. Why add a single point of failure to
package maintenance? (What if you or Pavel "disappear" for any reason?)

Have fun,

Patrick

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Robin H. Johnson]

On Thu, Nov 22, 2012 at 08:22:10PM -0600, Donnie Berkholz wrote:
> On 11:11 Sun 18 Nov , Robin H. Johnson wrote:
> > Here's a list of every package where I'm a maintainer and there is no
> > herd listed (but their might be other maintainers):
I didn't say I was dropping any of the packages, merely making an
explicit list of packages I maintain, that other developers are welcome
to touch - if they want to take them over explicitly, that would be
great too.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85

Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux

[Rich Freeman]

On Thu, Nov 22, 2012 at 9:09 PM, Donnie Berkholz  wrote:
> On 10:24 Fri 16 Nov , Dirkjan Ochtman wrote:
>> On Thu, Nov 15, 2012 at 8:42 PM, Justin  wrote:
>> > does anybody like to setup an Organization[1] profile @ ohloh for Gentoo?
>>
>> I've shot them a message, let's see what happens.
>
> Lemme know if you need any help pushing this through, I know the guy
> running it pretty well.

Ditto on the Foundation front if they need anything to make it official.

Rich

Re: [gentoo-dev] Reminder: open season on robbat2's packages

[Donnie Berkholz]

On 11:11 Sun 18 Nov , Robin H. Johnson wrote:
> Here's a list of every package where I'm a maintainer and there is no
> herd listed (but their might be other maintainers):
> dev-util/wiggle
> dev-vcs/cvs2svn

Suppose I could take these.

> dev-vcs/git

I'm hoping somebody is taking this?

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux 
Analyst, RedMonk 


pgplPH1rn4ntA.pgp
Description: PGP signature

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Donnie Berkholz]

On 23:57 Sat 17 Nov , Greg KH wrote:
> On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote:
> > I'm unsure on what grounds you disapprove. People start (and abandon)
> > projects often in Gentoo. Suddenly you dislike one such project and
> > object to this practice? Certainly if we had to get some sort of
> > Foundation consensus (for anything) nothing would happen. We can't
> > even get more than 40% of foundation members to vote.
> 
> I object if this is seen as a "Gentoo blessed" fork of a community
> project that is worked on by all other major Linux distros.  That is the
> type of decision that can be made by the Gentoo Council, which is fine,
> but it sure would be nice if it were publicly stated, instead of having
> to see it on the Gentoo github site instead.
> 
> And if that is the decision of the council, I would expect the ability
> to have some type of discussion about it, wouldn't you?

Sorry to follow up late but I feel like the critical point never made it 
clearly into this discussion.

The key misunderstanding here seems to be that initiation of a "Gentoo 
project" means that the council explicitly supports it, because in most 
distributions there is no choice available to end users at this level of 
detail.

Instead, in Gentoo, the council-level decision typically happens when 
the *default* changes. Non-default or non-mandatory things are handled 
in a nearly anarchic, ad hoc manner, where anyone can do pretty much 
whatever they want as an official Gentoo project.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux 
Analyst, RedMonk 


pgpFP4Q0Esq9W.pgp
Description: PGP signature

Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux

[Donnie Berkholz]

On 10:24 Fri 16 Nov , Dirkjan Ochtman wrote:
> On Thu, Nov 15, 2012 at 8:42 PM, Justin  wrote:
> > does anybody like to setup an Organization[1] profile @ ohloh for Gentoo?
> 
> I've shot them a message, let's see what happens.

Lemme know if you need any help pushing this through, I know the guy 
running it pretty well.

-- 
Thanks,
Donnie

Donnie Berkholz
Council Member / Sr. Developer, Gentoo Linux 
Analyst, RedMonk 


pgpeD65iNmfgq.pgp
Description: PGP signature

Re: [gentoo-dev] [PATCH python-r1] Move common utility functions to python-utils-r1.

[Michał Górny]

On Wed, 21 Nov 2012 10:30:29 -0500
Ian Stakenvicius  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 21/11/12 10:17 AM, Gilles Dartiguelongue wrote:
> > Le mercredi 21 novembre 2012 à 08:54 -0500, Ian Stakenvicius a
> > écrit :
> >> On 21/11/12 04:43 AM, Michał Górny wrote:
> >>> Moved: python_export, getters, python_domodule, python_doscript
> >>> and the necessary internal functions. No global-scope
> >>> variables, no phase functions. [ Snip! ]
> >> 
> >> So remind me again, in 10 words or less, why these shouldn't all
> >> stay in python-r1.eclass?  ie, what use case do we have for
> >> using python-utils-r1 but not python-r1 (or vice-versa, depending
> >> on which one inherits the other)?
> > 
> > From "[gentoo-dev] python-r1.eclass: the masterplan (dirty RFC)"
> > email:
> > 
> > Le lundi 12 novembre 2012 à 15:43 +0100, Michał Górny a écrit :
> >> 1) splitting common functions into python-utils-r1.
> >> 
> >> The python-utils-r1 eclass would provide means to work with
> >> specific Python packages like portage. Unlike python-r1, it would
> >> not export IUSE or require any specific USE flags.
> >> 
> >> I'm not insisting on this nor giving it a very high priority. It
> >> is a straightforward change since python-r1 will inherit the new
> >> eclass anyway.
> > 
> > 
> 
> 
> Ahh ok, so only very specific tools for very specific use cases.

You could say it's an algo like this:

1) if you want phase functions for distutils & all other automagic,
   use distutils-r1;

2) if you don't want phase functions but want PYTHON_TARGETS and other
   metadata stuff, use python-r1;

3) if you don't want phase functions nor metadata, just some random
   potentially useful functions, use python-utils-r1.

-- 
Best regards,
Michał Górny


signature.asc
Description: PGP signature

Re: [gentoo-dev] [python-single-r1 1/3] A conceptual eclass for packages not supporting multiple Python impls.

[Gilles Dartiguelongue]

Le mercredi 21 novembre 2012 à 23:19 +0100, Michał Górny a écrit :
> diff --git a/gx86/eclass/python-single-r1.eclass 
> b/gx86/eclass/python-single-r1.eclass
> new file mode 100644
> index 000..3d21ea8
> --- /dev/null
> +++ b/gx86/eclass/python-single-r1.eclass
> @@ -0,0 +1,93 @@
> +# Copyright 1999-2012 Gentoo Foundation
> +# Distributed under the terms of the GNU General Public License v2
> +# $Header: /var/cvsroot/gentoo-x86/eclass/python-r1.eclass,v 1.20 2012/11/21 
> 09:04:14 mgorny Exp $
> +
> +# @ECLASS: python-single-r1
> +# @MAINTAINER:
> +# Michał Górny 
> +# Python herd 
> +# @AUTHOR:
> +# Author: Michał Górny 
> +# Based on work of: Krzysztof Pawlik 
> +# @BLURB: An eclass for Python packages not installed for multiple 
> implementations.
> +# @DESCRIPTION:
> +# An extension of the python-r1 eclass suite for packages which
> +# don't support being installed for multiple Python implementations.
> +# This mostly includes tools embedding Python.
> +#
> +# This eclass extends the IUSE and REQUIRED_USE set by python-r1
> +# to request correct PYTHON_SINGLE_TARGET. It also replaces
> +# PYTHON_USEDEP and PYTHON_DEPS with a more suitable form.
> +#
> +# Please note that packages support multiple Python implementations
> +# (using python-r1 eclass) can not depend on packages not supporting
> +# them (using this eclass).
> +#
> +# Also, please note that python-single-r1 will always inherit python-r1
> +# as well. Thus, all the variables defined and documented there are
> +# relevant to the packages using python-single-r1.
> +
> +case "${EAPI}" in

you are missing the default EAPI value for EAPI=0 usually this is
written: case "${EAPI:-0}"

> + 0|1|2|3)
> + die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
> + ;;
> + 4|5)
> + # EAPI=4 needed by python-r1
> + ;;
> + *)
> + die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
> + ;;
> +esac
> +

The rest looks fine.