Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults

2010-06-28 Thread Thomas Anderson
On Mon, Jun 28, 2010 at 01:40:46PM +0530, Nirbheek Chauhan wrote:
 On Mon, Jun 28, 2010 at 1:38 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
  On 06/28/2010 10:51 AM, Ciaran McCreesh wrote:
  Will Gentoo be doing the same for -Ofast and its flags then? After all,
  most packages work with them, and you can't let the few packages that
  require standard-compliant behaviour from a compiler hold Gentoo
  hostage.
 
 
  This is not about optimizing but preventing clear breakage, the benefits
  of asneeded are not under debate here (like already stated in the
  original message this thread started from)
 
  So please stop trying to derail the thread
 
 
 ++, all of this has been discussed to *death*.
 
 
 -- 
 ~Nirbheek Chauhan
 
 Gentoo GNOME+Mozilla Team
 

Not taking technical sides in this thread simply because I have no time to
argue it at length, BUT:

Simply because a topic has been discussed to *death* does not mean the
correct answer was obtained, only that a majority agree it is what they
want. And while consensus may be enough to be considered 'right' in social
situations(politics, etc.), the second the discussion becomes technical the
opinion of the masses becomes irrelevant. All that then matters is getting
the technical part objectively right, which IS possible, despite what some
may say.

Regards,
Thomas
-- 
-
~Thomas Anderson~
-




Re: [gentoo-dev] Election for the Gentoo Council empty seat

2009-12-30 Thread Thomas Anderson
On Tue, Dec 15, 2009 at 11:57:41PM -0100, Jorge Manuel B. S. Vicetto wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hello.
 
 As announced by Denis (Calchan)[1], we need to have an election for the
 Gentoo Council's empty seat.
 We'll be putting up a page with all the information for the Council
 election, including the election officials, asap. I'll send another
 email later with the link and the missing information, but for now, let
 me just share the dates for nomination and voting:
 
 nomination: December 17th to 30th
 voting: January 1st to 14th
 
 To nominate anyone for the empty seat, please send an email to the
 gentoo-dev ml. Anyone can nominate for the Council, but only current
 Gentoo Developers can stand for and vote in the election.
 
 If you have any doubts, please contact me in IRC, you can use the
 elections project channel[2], or email the Elections team[3].

I nominate tanderson. And I (obviously) accept. :)
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




Re: [gentoo-dev] Re: [RFC] Add operator + for licenses (EAPI-4 ?)

2009-09-05 Thread Thomas Anderson
On Sat, Sep 05, 2009 at 04:03:25PM +0200, Maciej Mrozowski wrote:
 On Friday 04 of September 2009 22:08:02 Ciaran McCreesh wrote:
  On Fri, 04 Sep 2009 22:04:46 +0200
 
  R?mi Cardona r...@gentoo.org wrote:
   Having tools to manipulate those variables is very misleading since
   users will (rightfully) assume that we've done our homework and that
   upstream did too.
 
  Why not use EAPI 4 to make sure people have done that homework then?
 
 Because it won't make *upstream* do their homework.
 I suppose you volunteer to make this homework for Gentoo to fulfill new EAPI 
 requirements as I assume your lawyer skills equals the will to propose yet 
 another EAPI.
 Therefore I fully support this idea.
 
 -- 
 regards
 MM

What is your point? If your goal is to come across as a bitter person with a lot
of hate then you've succeeded. Tone it down please as you're not contributing
anything useful to the discussion like that.

Ciaran's really not making homework up for gentoo. Why, remi stated himself that
we have homework to do(and we sometimes don't do that homework) so unless you're
just trying to pick a fight I don't see what you're trying to say. Please don't
do that.


Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpJDFjjFKKHd.pgp
Description: PGP signature


Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)

2009-08-30 Thread Thomas Anderson
On Sun, Aug 30, 2009 at 07:06:02PM +0200, Mounir Lamouri wrote:
 Hi,
snip
 However, dying is probably not the best solution too.
 So I think we should add a new feature in PMS already used in Exherbo
 EAPI, USE flags requirements [1]. That means an ebuild should be able to
 say a USE flag is available only if some other ones are in a specific state.
 Let's take the mplayer example, if we have a line like this:
 USE_REQUIREMENTS=encode? ( mp2 mp3 faac x264 xvid ), PM should be able
 to show the user USE=mp3 will be ignored because he didn't set
 USE=encode and the PM will disable this USE flag by himself.
 The same way, for ekiga:
 USE_REQUIREMENTS=kde? ( kontact ), PM should be able to show the user
 if he set USE=kontact, kde USE flag is enabled and the PM will enable
 this USE flag by himself.

I'm not sure acting as if the user didn't enable the USE flag is the best
option. If I manually enable the bar USE-flag I might not expect there to be an
issue and not notice that it has been silently ignored. In general I think we
should take the approach that if we can't give a user what he/she asked for we
should error out and tell him/her that there was a problem and that
such-and-such needs to be changed.

 I'm not writing a GLEP draft so don't try to found an issue in the
 syntax used, it's only to know if this kind of feature will be
 appreciated by other users/devs than me and if it could be added to
 EAPI-4 and worth to work on it.
 I can write the GLEP and implement the feature in portage.

I very much would like this feature. I've been using it in Exherbo and it's
quite useful so far. Only thing is that it'll be possible to do this sort of
thing(only you'll have to || die) with EAPI-3 as a 'if use foo; then use bar
|| die foo needs bar'. The question is whether it is worth it to have this
special construct for USE-flag combinations(there're far more possibilities than
the one I gave), and I'd say it is worth it.
 
 [1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions
 
 Thanks,
 Mounir
 

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpC6dfSRDZwM.pgp
Description: PGP signature


Re: [gentoo-dev] Re: EAPI 3 and nonfatal die

2009-08-24 Thread Thomas Anderson
On Mon, Aug 24, 2009 at 08:20:44PM +0200, Christian Faulhammer wrote:
 Hi,
 
 Ryan Hill dirtye...@gentoo.org:
 
  On Fri, 21 Aug 2009 21:56:41 +0100
  David Leverton levert...@googlemail.com wrote:
  
   Does anyone have any opinions on which of the four options (#1
   make die respect nonfatal, #2 make die always die, #3 add a new
   die variant that respects nonfatal, #4 make regular die respect
   nonfatal, and add a new variant that doesn't) we should go with?
   We should definitely get this resolved and agreed on before EAPI
   3 is finalised.
  
  I'd like die to respect nonfatal.  People using nonfatal should check
  beforehand that the functions they're calling won't do anything
  stupid if die's are ignored.  If there's something that absolutely
  has to die, nonfatal or not, then use a variable.  I guess that's #4?
 
  I agree here (yes, I know, a ME TOO posting, but I say this as PMS
 team member).

I must agree here too as a PMS team member. so 'me too' :P

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgp1DcsVBwPus.pgp
Description: PGP signature


Re: [gentoo-dev] Keeping profiles/ tidy

2009-08-03 Thread Thomas Anderson
On Sat, Aug 01, 2009 at 11:09:16PM +0300, Samuli Suominen wrote:
 Nirbheek Chauhan wrote:
  On Sat, Aug 1, 2009 at 7:32 PM, Petteri R??tybetelge...@gentoo.org wrote:
  Nirbheek Chauhan wrote:
  This seems like something that should be added to the ebuild/end quiz.
 
  Ebuild quiz:
 
  19. What is the procedure for removing packages from the tree?
 
  
  Looking back, my answer to that question was insufficient, so the
  answer needs to be fixed ;)
  
  
 
 19. What is the procedure for removing packages from the tree? Do you
 need to do something in profiles/ after removing? If yes, what would it be?
 
 -Samuli
 

In general, the quiz is supposed to test and educate recruits about Gentoo
development practices. But if all parts of a question are asked in questions
like that(where it's obvious that 'no' isn't a valid answer) it's just going to
result in more googling rather than thinking hard and having knowledge about how
and why it's done. I think the original wording is fine because the recruit will
have to think hard about what else is needed and consult documentation without
knowing exactly what he is looking for. If needed the mentor can help out with
points like that, but if at all possible it should be initially answered by the
recruit.

So please, let's not make the quiz into a set of yes/no questions(an
exaggeration I know, but still the same effect).

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpWVSjMmFZcn.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Re: Council meeting summary for meeting on June 11, 2009

2009-06-28 Thread Thomas Anderson
On Sat, Jun 27, 2009 at 11:34:48AM +0100, Steven J Long wrote:
 Thomas Anderson wrote:
 
  Steven J Long wrote:
  Denis Dupeyron wrote:
  
   This list is for technical discussions only.
  I look forward to the day when that actually happens, and we are not
  regaled with countless emails about technical issues that were solved 3
  years ago, accompanied by juvenile insults at anyone who might disagree.
  
  
  Speaking of juvenile insults, your last mails concerning my summary have
  had their fair share of insults towards me(all unfounded and ridiculous).
  Would you please stop that?
 
 I still can't see any insults; I was actually doing my best to give you the
 benefit of the doubt. Clearly you are fairly immature, based on my
 interaction with you over the last 3 years, and you did indeed take part in
 a concerted political action, which was not at all what it was claimed to
 be.

There were no political actions ocurring, I was doing my job. As for insults, I
was referring to:

This is inaccurate, and to be frank, a lie.

And sorry, tanderson, but consider my words of support for your campaign
rescinded after the concerted nature of your part in the politicking. --- Not
exactly an insult but sort of close considering it's not true; call it libel.

You clearly have a year or two more of growing-up to do, minimum, AFAIC.

Nice summaries though. Not exactly an insult though it was probably sarcastic.

And of course the insult in the last mail you sent: Clearly you are fairly
immature and ignoring the libel about political actions(which is both
unsubstantiated and untrue).

And other in general attitude problems against me.
   Also, public mailing-lists
   are not for discussing your personal issues.
  
  It wasn't my personal issue; it was about an inaccurate summary and a
  Council member blatantly lying and using his position for partisan aims.
  
  The summary was not innacurate; If someone is banned, I put down the
  reason given _at the time_ for the banning. That seems fairly
  straightforward. There is nothing biased(or anything deserving being
  called a 'lie') in that summary
 
 You weren't the Council member referred to. You really don't appear to have
 considered my point of view very much.

So if I don't agree with you and stand up for the work I've put into something I
merely haven't considered what you said? My work is on the line as is my image
of journalism and I certainly double check everything to make sure I am not in
the wrong.

  I do my best at professional journalism(I am an amateur however) and your
  remarks to the contrary show you haven't given thought to how much time
  and effort I spend at making it unbiased and accurate.
 
 You need to think about not simply putting one side of a story in order to
 maintain the appearance of impartiality. Which, as you took part in the
 politicking, you didn't have in any case.

Please, point out *how* I politicked(especially in my summary). I think you'd
be rather surprised at the outcome. Also point out how I could have been more
impartial so I can improve my process.

 As for your time and effort, you put that in because you want to. While I
 appreciate it, I also appreciate how much time and effort everyone else
 puts in too; most especially the users without whom nothing would get done.

You twisted that sentence of mine. I didn't say you should think twice about it
being innacurrate because I put a lot of work into the summary, I said it
because I had put a lot of work into trying to make it impartial.

  You can keep on doing things badly all you like; just expect to get
  picked up on it when you summarise it inaccurately in the archives.
  
  See above, especially the part saying for what he called.
 
 I was answering the censor him! tendency that is so prevalent when Gentoo
 devs are being picked up on their behaviour and so reviled when it means
 disallowing constant poisonous trolling. IIRC the argument is that it reads
 like 'lex ciaran'; perhaps that's more an indication of how trollish ciaran
 actually behaves than a direct attack on him.

By that logic you should be silenced for what I know is trolling in this thread.
Think it's fair?


  Certainly seems to be what you're best at, after all. Ah oh yes, you're
  the person who stated user-rel wanted Council to review the decision,
  which they said they did not. Curious that you should ignore all the
  points about process and try to make out this is my personal issue and
  not an issue of borked process.
  
  I believe the Council was deciding only on what to do in #-council which
  is as stated their turf. Any userrel issues are probably separate to this
  problem.
 
 Hmm firstly I was directly addressing one individual about his actions. He
 raised it; either let him answer as to his intent, or speak for yourself.

Well considering you were replying to *me* on the list it is a logical deduction
that you were talking to me. But sorry for that.
 
 Perhaps you should re-read

[gentoo-dev] Gentoo Council Reminder for June 25

2009-06-22 Thread Thomas Anderson
(This is late because I was traveling and dev-zero is/was on devaway.)

This is your friendly reminder! Same bat time (typically the 2nd  4th
Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @
irc.freenode.net) !

If you have something you'd wish for us to chat about, maybe even vote
on, let us know! Simply reply to this e-mail for the whole Gentoo dev
list to see.

For more info on the Gentoo Council, feel free to browse our homepage:
http://www.gentoo.org/proj/en/council/


Attached is the preliminary meeting agenda.


-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-
Define EAPI development/deployment cycles
-

Last meeting several members expressed support for Ciaran McCreesh's
suggestions[1]. The discussion got sidetracked however and no consensus was
reached.

Goal: Decide on and approve a set of development and deployment guidelines
for future EAPIs.

EAPI 3 Progress
---
zmedico will provide an update on the progress of the implementation in 
portage.
If Brian Harring(ferringb) is present, he will give an update on the 
progress of
the implementation in pkgcore.

Discuss Past Year
-
Since this is the last meeting of the outgoing some asked for a discussion
of the last year's accomplishments and obstacles for the next council to be
aware of. In order for this to be productive the channel may have to be
moderated.

[1]: 
http://archives.gentoo.org/gentoo-dev/msg_d3a4758c455fded00608e891f525d3cc.xml


pgp9YRvJrNdzK.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Re: Council meeting summary for meeting on June 11, 2009

2009-06-21 Thread Thomas Anderson
On Sun, Jun 21, 2009 at 08:09:04AM +0100, Steven J Long wrote:
 Denis Dupeyron wrote:
 
  This list is for technical discussions only.
 I look forward to the day when that actually happens, and we are not regaled
 with countless emails about technical issues that were solved 3 years
 ago, accompanied by juvenile insults at anyone who might disagree.
 

Speaking of juvenile insults, your last mails concerning my summary have had
their fair share of insults towards me(all unfounded and ridiculous). Would you
please stop that?

  Also, public mailing-lists
  are not for discussing your personal issues.
 
 It wasn't my personal issue; it was about an inaccurate summary and a
 Council member blatantly lying and using his position for partisan aims.

The summary was not innacurate; If someone is banned, I put down the reason
given _at the time_ for the banning. That seems fairly straightforward. There is
nothing biased(or anything deserving being called a 'lie') in that
summary(notice I used the language for what he called indicating that this is
not necessarily my view or the council's view of what occurred, only what reason
was given for the banning). As those who I talk to can attest to, I bend
over backwards to make sure all my summaries are professional and indicate what
the person means, not what others say about their intentionns etc.

I do my best at professional journalism(I am an amateur however) and your
remarks to the contrary show you haven't given thought to how much time and
effort I spend at making it unbiased and accurate.

 You can keep on doing things badly all you like; just expect to get picked
 up on it when you summarise it inaccurately in the archives.

See above, especially the part saying for what he called.
 
 Or like, y'know, put your house in order/ keep that crap outta the archives.
 I don't have any more to say on it, but feel free to keep the flamefest
 going amongst yourselves.

See above.

 Certainly seems to be what you're best at, after all. Ah oh yes, you're the
 person who stated user-rel wanted Council to review the decision, which
 they said they did not. Curious that you should ignore all the points about
 process and try to make out this is my personal issue and not an issue of
 borked process.

I believe the Council was deciding only on what to do in #-council which is as
stated their turf. Any userrel issues are probably separate to this problem.

 
 As stated, summarise correctly, and even better, follow a more professional
 process, and this sub-topic would never have been raised.

See above.

 As it is, this is
 about the level of debate I expected; blame the messenger, and avoid our own
 problems. I am glad there's an election on.

So am I, but your slandering of my platform is not appreciated at all.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgphDvbKl3t5P.pgp
Description: PGP signature


[gentoo-dev] Council meeting summary for meeting on June 11, 2009

2009-06-17 Thread Thomas Anderson
Here is the summary from Thursday's council meeting. The full log along with the
summary will appear shortly at http://www.gentoo.org/proj/en/council.

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-
Roll Call:
===
Betelgeuse: here
Cardoe: here
dertobi123: here 
dev-zero: here
leio: here
lu_zero: here
tanderson(secretary): here
ulm: here

Topics:
===

 - Short discussion of EAPI 3 progress.
Zac Medico(zmedico) commented that while no progress had been made, a
tracker bug had been made[1] for those interested in providing patches
for and tracking the progress of the EAPI 3 implementation. Ciaran
McCreesh noted that paludis is ready for EAPI 3 whenever the portage
implementation is finished.

- Default contents of ACCEPT_LICENSE(license filtering).
GLEP23[2] provided a method for users to select what licenses they are
willing to accept based on a ACCEPT_LICENSE configuration variable. In
addition it provided for 'license groups' so users could accept or
decline to use software of a certain license type. What GLEP 23 did not
specify was the default value of ACCEPT_LICENSE.

Conclusion:
The council unanimously voted to have the default ACCEPT_LICENSE
value as ACCEPT_LICENSE=* -...@eula.

- BASH 4 in EAPI 3.
There were three parts to this topic:
1) Unlocking of feature requests for EAPI 3.
2) Allowing BASH 4 features in EAPI 3 ebuilds.
3) Allowing BASH 4 features in all ebuilds with EAPIs = 3 after a 
   fixed amount of time in gentoo-x86(Overlays could begin use
   immediately).

Conclusion:
By a 4-3 decision the council voted not to open the feature list for
EAPI 3.

- The banning of igli(Steve Long) from #gentoo-council.
Tiziano Muller(dev-zero) banned igli from #-council for what he called
repeated trolling after private warnings. The ban was later reversed by
Doug Goldstein(Cardoe) because it had not been put to a council vote as
all bans in #-council are.

Conclusion:
No decision yet, the council decided to discuss this issue privately
on the council@ alias so that precious meeting time is not spent.

- Define EAPI development/deployment cycles.
Various Council members expressed support for Ciaran McCreesh's EAPI
development guidelines as outlined in [3]. However, the discussion
reached no conclusion and quickly spiraled into a discussion of the
removal of Ciaran McCreesh's bugzilla privileges.

- Removal of Ciaran McCreesh's(ciaranm) bugzilla permissions.
At some point in the last year ciaranm's bugzilla permissions were
removed. He filed a bug about the issue(#273759) and was talking about
moving PMS off of Gentoo Infrastructure, a move that some council
members were strongly opposed to. When asked about the permissions,
Ciaran had no objections to waiting a few days for the infra to complete
an investigation into who removed the access and for what reason.

Conclusion:
The council voted to reinstate Ciaran's editbugs privileges. Ned
Ludd (solar) noted that infra will investigate who removed the 
privileges
in the first place, and asked for not changing bugzilla privileges 
before
this is completed.

[1]: https://bugs.gentoo.org/show_bug.cgi?id=273620
[2]: http://www.gentoo.org/proj/en/glep/glep-0023.html
[3]: 
http://archives.gentoo.org/gentoo-dev/msg_d3a4758c455fded00608e891f525d3cc.xml


pgpoEOF6TmZB9.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

2009-06-07 Thread Thomas Anderson
On Mon, Jun 01, 2009 at 11:25:54PM +0200, Dawid W??gli??ski wrote:
 On Monday 01 of June 2009 06:25:06 Jorge Manuel B. S. Vicetto wrote:
  Hello fellow developers and users.
 
 
 I nominate:
 
 Betelgeuse
 Calchan
 peper
 darkside
 tanderson
 Cardoe
 

Thanks Dawid, Mounir, and Tiziano, I accept.

My manifesto is available at [1], please remember to vote for
gentoofan23, not tanderson(irc nick). ;-)

Regards,
Thomas

[1]: http://dev.gentoo.org/~gentoofan23/2009Manifesto/manifesto.html
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpghcOixEpJa.pgp
Description: PGP signature


[gentoo-dev] Council meeting summary for meeting on May 28, 2009

2009-06-04 Thread Thomas Anderson
Here is the summary from Thursday's council meeting. The full log along
with the summary will appear shortly at
http://www.gentoo.org/proj/en/council

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-
Roll Call:
===
Betelgeuse: here
Cardoe: here
dertobi123: here 
dev-zero: here
leio: here
lu_zero: here
tanderson(secretary): here
ulm: here

Topics:
===

- Filling the empty council seat.
Donnie Berkholz resigned from the council so there is an empty spot
that needs to be filled. ssuominen and ulm were tied for the next
spot, but ssuominen relinquished his seat to ulm. To fill the spot,
ulm needed to be unanimusly voted in by the current members.

Conclusion:
Unanimously voted to fill the seat. Ulrich M??ller will fill Donnie
Berkholz's seat for the rest of the current term.

- EAPI 3 status report from Zac Medico.
No progress yet. Zac said he'd have a recent recruit of his work with
him on it.

Conclusion:
Zac will work on EAPI 3 features with the help of his recruit. He
will also blog about what features need to be done so the general
community can pitch in.

- Removal of Old Eclasses.
Jorge(jmbsvicetto) requested that the council discuss removing
eclasses from the tree that are no longer needed. The problem with
this is that old(2.1.4) portage versions used the eclasses from the
tree to run uninstall phases. Thus, the removal of eclasses would
break users who have a portage older than 2.1.4.

Conclusion:
The council voted that to remove eclasses devs should take the
following steps:
1) Deprecate eclasses.
2) Removal of all functionality relating to installing.
3) After two years the eclass may be removed.
Thomas Anderson(tanderson) will write up patches for devmanual so
that this policy is documented.

- Handling EAPI Versioning in a forwards-compatible way.
Various developers have raised concerns that GLEP 55 only describes a
solution and doesn't clearly show the problems being solved(if any).
Luca(lu_zero) mentioned a few things in the Problem section that he
thought could be clarified, listed below:

1) For Change the behaviour of inherit in any way, it would be
useful to include references to bugs where requested inherit
changes would require GLEP 55.

2) For Add new global scope functions in any way, defining
'Sane'.

3) For Extend versioning rules in an EAPI, removal of all
mentions of GLEP 54 would remove circularity. In addition,
mentioning other version format changes would be useful.

4) For Use newer bash features, listing useful(including
in-tree) bash features not available in the bash version mandated
by PMS would be useful.

Conclusion:
The council voted on whether they recognized the problem that GLEP
55 is attempting to solve is real. The vote was affirmative in
recognition of the problem with two abstentions(leio and ulm). '
Cardoe was no longer at the meeting for this vote and will post 
his voteon-list.


pgplohe0EcPkQ.pgp
Description: PGP signature


[gentoo-dev] A different approach to reaching (more) agreement on glep 55

2009-06-01 Thread Thomas Anderson
Hi,

A lot of what I've seen in these past few months is a lot of
bickering and disagreement over glep 55. I don't think that has to
be. A glep shouldn't be political but should evolve as people bring
up points to change and refine it. I haven't seen that been
happening, so I'd like to guide the discussion in a more positive
direction.

So, if you could email the list with specific things you'd like to
see refined or things that do not  make sense to you. Basically, a
list of things to be clarified. Luca presented some in the last
council meeting regarding the Problem section, but I'd like to open
this up to the whole glep. As always, Patches welcome.

Please note, this thread should not turn into a long discussion, and
no subthread should contain 3 messages, so if you see that while
writing a mail, please don't send your undoubtedly unconstructive
comment(or it'll be impossible to wade through the thread looking
for constructive stuff which is the point of the thread).


Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpaPTDlYSqvw.pgp
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-17 Thread Thomas Anderson
On Sun, May 17, 2009 at 12:35:43AM -0400, Richard Freeman wrote:
 Ravi Pinjala wrote:
 Nick Fortino wrote:
 Such a transformation is possible, given the restrictions on arg, as
 well as ebuild format.
 Isn't this a bit circular? The whole point of wanting to change the
 extension is to get rid of exactly these restrictions; if you assume the
 restrictions, then the whole thing is kind of pointless. :)

 What restrictions?  The restriction that EAPI be fixed on the 5th line of 
 the build, or the restriction that EAPI be fixed in the filename.  I don't 
 really see much difference between them.  What can the one do that the 
 other can't.

The difference is that putting the EAPI in the filename has backwards
compatibility because package managers not knowing about this change
won't even look at the those ebuilds. Putting EAPI as the fifth line
completely loses this, so as far as backwards compatibility goes putting
EAPI 55 in the filename really is the cleanest.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpTTGoJ1MWDK.pgp
Description: PGP signature


Re: [gentoo-dev] The fallacies of GLEP55

2009-05-16 Thread Thomas Anderson
On Sat, May 16, 2009 at 10:05:08PM +0530, Arun Raghavan wrote:
 On Sat, 2009-05-16 at 16:49 +0100, Ciaran McCreesh wrote:
  On Sat, 16 May 2009 17:43:32 +0200
  Tobias Klausmann klaus...@gentoo.org wrote:
That doesn't let us do version format changes.
   
   Or are we talking about the *ebuild* versions? I see that as
   different matter. Plus: You could change the version format with
   the changed extension. I sure do hope there are no plans on
   making those changes as often as new EAPIs.
  
  Yes, those. The current rules include some pointless arbitrary
  restrictions that are only there for historical reasons and that mean
  people have to mess with convoluted MY_PV things.
 
 So from all the debate that's going on, the current major issue seems to
 be being able to support '-scm' as per GLEP-54. What other restrictions
 in the version format are you referring to?
 
 -- Arun

For one, there's the restriction that all *-alpha/*-rc has to be
represented _rc/_alpha. I plan on doing more research into perhaps
lifting this restriction in a future EAPI, but this would of course
require glep 55's solution.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development

2009-05-13 Thread Thomas Anderson
On Tue, May 12, 2009 at 08:35:41AM +0200, Patrick Lauer wrote:
 On Tuesday 12 May 2009 00:31:36 Ciaran McCreesh wrote:
  On Mon, 11 May 2009 23:17:32 +0100
 
  George Prowse george.pro...@gmail.com wrote:
   An equilibrium seems to have been reached which currently works.
 
  An equilibrium has been reached, agreed, but that it works is up for
  debate. There is a strong argument to be made that preserving the
  equilibrium will keep Gentoo the way it is now -- delivering at best the
  same user experience now that it was several years ago, in an
  increasingly difficult and more competitive environment.
 
 Then there's package management. (Your favourite topic, I guess, because you 
 want to keep complexifying it until one needs a PhD to write an ebuild 
 [which, 
 in a way, would be quite ironic])

Same as Petteri here, new EAPIs make ebuilds easier to write for me, not
harder.

 
 And now you say delivering the same user experience ... 
 ... ignoring the tons of new features and things that have happened. You're 
 being dishonest again in an attempt to make us look like baboons. Two thirds 
 of the new features grew on your compost heap (and half of these features we 
 didn't even want, but after about three years of you pushing them at every 
 opportunity people are getting so demotivated that they are willing to let 
 you 
 have one feature if you just STOP WHINING for more than 10 minutes)[GLEP55, 
 for example - there's about 8 people that want it, but those keep bringing it 
 up at EVERY opportunity. It's still a fundamentally stupid idea that doesn't 
 solve any problems, and the claim that it might solve problems we have in the 
 future is quite asinine because we can do the changes then, _if_ the 
 theoretical problems actually become an issue, without messing up most 
 everything now for some hypothetical gain that has not even conclusively 
 shown 
 ...]

I'd wager there are more than 8 people that want it, but even so, just
because not many people realize its usefulness doesn't mean it's a bad
proposal(unpopular decisions != bad decisions, in other words).

The changes we want are something that we want soon, but there's nothing
we can do until something solving the problem GLEP 55 is solving is
approved.

Also, please stop the compost heap, whining etc. It's tantamount to
a personal attack.

 
 - We're not in a bad shape, dying or dead. We don't intend to. 

Few empires intend to die, but I'd agree that we're not dying/dead ;-).

 
 - More complex doesn't mean better.
 Perfection isn't when you cannot add more things but when there are none 
 left 
 to remove or how that quote went. You know what I mean. Rewriting the init 
 scripts in XML might be what some call progress (now you can verify 'em!), 
 but 
 it doesn't actually add any value and complexifies things in a bad way

I've not seen anything complexifying things for no benefit recently.
Care to mention those?
 
 - Repeating a lie can make it true, if you repeat it long enough. Worst case 
 you just have to wait until everyone who disagrees dies of old age.
 

Most things people are calling lies I'd call more opinions that I
disagree with. We really do dramatize and bring too much importance on
disagreements ;-). Also, I imagine you're talking about glep54/glep55
none of which there have been lies spread by their proponents(that I've
seen).

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpvTyZVF4HXT.pgp
Description: PGP signature


Re: [gentoo-dev] `paludis --info' is not like `emerge --info'

2009-05-09 Thread Thomas Anderson
On Wed, Feb 18, 2009 at 11:22:12PM +0100, Jeroen Roovers wrote:
  Hi folks,
 --info' is asked for in a bug report, post *that*. There are many
 examples of what should be included out here, so if you can't or won't
 use emerge, then you'll have to copy the information manually.
 Remarking that you don't use emerge is not a valid reason not to post
 it - post both `(emerge|paludis) --info' if you must - having both
 there will help greatly and is necessary for the time being[1].
 

Folks, I'd like to direct your attention to bug #269067. In this case,
had the bugwrangler(yngwin) asked for paludis --info the bug could have
been RESO INVALID without it getting to me. I wouldn't have wasted ~30
minutes deciding that the user was being crazy.

So yes, paludis --info can come in handy, and I found it useful in this
case.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpChNtYrEc3r.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development

2009-05-07 Thread Thomas Anderson
On Thu, May 07, 2009 at 12:29:33PM +, Duncan wrote:
 Marijn Schouten (hkBst) hk...@gentoo.org posted
 4a02a0e7.5050...@gentoo.org, excerpted below, on  Thu, 07 May 2009
 10:50:47 +0200:
 I've seen a few replies from the (rare) Gentoo dev as well, indicating 
 they basically don't do IRC either, just mail, tho it is quite rare, and 
 it would seem, likely to go extinct in Gentoo before its time, since 
 evidently those devs have no skills considered worth recruiting any 
 more.  I'd call that a shame as that's a potentially large skills and 
 talent bank Gentoo's about to pass on, but what's a man to do, other than 
 make the point as best he can? shrug  

It seems to me you're on a irc-hate rampage. There are many devs who
rarely, if ever, go on irc. The _only_ requirement is that  you conduct
a real-time interview with a recruiter. It's sort of like a job
interview only it's remote. Once you're a dev you don't have to go on
irc _at all_. It's not going to kill you to do two reviews on irc,
especially given the advantages various people have presented for a
real-time interview.

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgppB6HZ5Ub0z.pgp
Description: PGP signature


Re: [gentoo-dev] Retiring

2009-05-05 Thread Thomas Anderson
On Tue, May 05, 2009 at 05:06:43PM +0300, Markos Chandras wrote:
 On Tuesday 05 May 2009 16:50:47 Richard Freeman wrote:
  Arch
  teams seem to be generally doing a good job keeping up with STABLEREQs
  on the major archs - if you use a minor arch that isn't as well
  supported I'm sure we'd be happy to have more help.
 Arch teams, according to their project pages, are in a good shape. Major 
 arches have enough people ( assuming that the project pages are up2date )

The amd64 project page at least is definitely not. We have a ton of
slackers. I'd venture to say most in the project don't actively work on
amd64 at all. We are handling the load fairly well though.

Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgp7QZdeBowcq.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council Reminder for May 7

2009-05-04 Thread Thomas Anderson
On Mon, May 04, 2009 at 02:06:47PM +0300, Petteri R??ty wrote:
 Isn't it second and fourth Thursday?
 
 Regards,
 Petteri
 

That's an oversimplification. That varies because of when we have some
holidays and skip meetings, throughing the schedule off. It's easiest to
remember it as every other thursday.


Thomas


-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in mail-mta/courier: ChangeLog courier-0.61.2.ebuild

2009-05-04 Thread Thomas Anderson
 S=${WORKDIR}/${P}
You don't need to set this, it's the default.

 filter-flags '-fomit-frame-pointer'

filter-flags in global scope? You should put that in
src_unpack/src_prepare.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpZISbaDHSSC.pgp
Description: PGP signature


Re: [gentoo-dev] Gentoo Council Reminder for April 23

2009-04-19 Thread Thomas Anderson
On Sun, Apr 19, 2009 at 05:58:53PM +0200, Peter Alfredsen wrote:
 On Fri, 17 Apr 2009 15:17:15 -0700
 Donnie Berkholz dberkh...@gentoo.org wrote:
 
  If you have something you'd wish for us to chat about, maybe even vote
  on, let us know! Simply reply to this e-mail for the whole Gentoo dev
  list to see.
 
 Up or down vote on USE=static-libs. It seems it wasn't actually voted
 on last time it was brought up. We now have EAPI=2 use-deps and I just
 committed dev-util/lafilefixer for the .la file problems. I see no more
 obstacles for getting this adopted.
 
 /loki_val

Why are we trying to get rid of static libraries again? I have not seen
any compelling reason to remove libraries that may be useful to our
users. Perhaps I've missed some discussion(in which case, I'd love to
read it), but this seems like an unnecessary complexity.
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpDpweUzQ8PB.pgp
Description: PGP signature


Re: [gentoo-dev] EAPI 3 PMS Draft

2009-03-16 Thread Thomas Anderson
On Mon, Mar 16, 2009 at 11:59:45PM +0100, Maciej Mrozowski wrote:
 On Monday 16 of March 2009 21:47:17 Ciaran McCreesh wrote:
  I've got a very rough draft of what EAPI 3 might end up looking like,
  based upon discussion:
 [cut]
 
 Nice work.
 To avoid further confusion I'd suggest removing all traces of kdebuild- 
 format 
 and its features (like PDEPEND labels, ranged dependencies) from PMS 
 document, 
 especially its references to Gentoo KDE project.
 It has not been accepted thus should not exist in Gentoo PMS document.

While I'm sure there will be arguments for and against this, their merit
really does not matter. What matters is that this is completely offtopic
for the question of what should be in EAPI 3, and those feature's
specification. Please please do not associate the two as it'll just
prolong the acceptance of EAPI 3, and we all know we don't want that.

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




Re: [gentoo-dev] Re: devs on IRC (was :Regen2 ( was QA Overlay Layout support ))

2009-03-13 Thread Thomas Anderson
On Fri, Mar 13, 2009 at 03:37:28PM +, Duncan wrote:
 Thilo Bangert bang...@gentoo.org posted
 200903101315.52142.bang...@gentoo.org, excerpted below, on  Tue, 10 Mar
 2009 13:15:36 +0100:
 
  the presumption seems to be, that as a dev one has to be available via
  IRC. it has long been my feeling that Gentoo as a project could realize
  more of its potential by better integrating people who dont do IRC.
 
 This has bothered me too.  Some people simply don't do well in 
 immediate (textual) communication mode.  They much prefer the minute-
 resolution mode of email/web-form/newsgroup to the second-resolution mode 
 of IRC/IM.  I'm one such person.[1]  As a result, I have experienced a 
 high barrier to getting further involved with Gentoo, toward becoming an 
 AT or dev.

There are many devs who rarely venture on IRC, yet do a lot of good
work. As far as ATs go, it's not a necessity to be on IRC; pretty much
the only communication that occurs in #-amd64-dev is coordination of
stabilization efforts and goofing off(and the occasional xfce dev talks
:p).
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




Re: [gentoo-dev] Ideas for a (fast) EAPI=3

2009-03-08 Thread Thomas Anderson
On Sun, Mar 08, 2009 at 09:42:29AM -0700, Donnie Berkholz wrote:
 On 08:49 Sun 08 Mar , Tiziano M?ller wrote:
  So I think it's time for a short eapi bump with some distinct
  improvements:
  
  http://spreadsheets.google.com/ccc?key=pPAJXP6shYH78lCXeqRqCUQ
 
 - I understand the reasoning for the SRC_CONFIGURE_WITH blah stuff. I 
 strongly oppose this implementation because it makes ebuilds less like 
 bash scripts that are easy to understand. Instead I suggest extending 
 use_with() and use_enable() to accept multiple sets of arguments 
 (alternately, making custom, similar functions that will take multiple 
 args). Combined with the addition of src_configure() in EAPI=2, the 
 amount of code could be a large reduction from existing versions without 
 raising the barrier to entry.

While I understand your concerns about the SRC_CONFIGURE stuff, there
are two points I'd like to make;
1) The barrier to entry is negligible. How much more difficult is it for
someone to learn what CONFIGURE_ENABLES=( 'foo foobar' ) ? I didn't find
it difficult at all(and I've used them).
2) src_configure is just one part; src_compile has uses as does
src_install. In fact, if you want to do patches, src_prepare would be in
there too. What I'm saying is that focusing on the one part(configure)
is ignoring the good part of the rest of the proposal.

Regards,
Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgp4mn7bM5lm2.pgp
Description: PGP signature


Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-25 Thread Thomas Anderson
On Wed, Feb 25, 2009 at 04:56:04PM +0100, Luca Barbato wrote:
 Yes, it will warn noisily. This is unacceptable, since stable users
 will have months and months of noise when new rules come along.

 unacceptable...

 as in it's ugly to see...


No, it's unacceptable because stable users do not need that kind of
stuff thrown at them. Stable users use stable because they want a very
predictable workflow. Noisy errors that shouldn't affect them(they are
in the stable branch) *is* unacceptable, and not just because it's ugly,
though that's certainly part of it.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives

2009-02-25 Thread Thomas Anderson
On Wed, Feb 25, 2009 at 12:21:23AM +0200, Petteri R??ty wrote:
 1) Status quo
   - does not allow changing inherit
   - bash version in global scope
   - global scope in general is quite locked down

Yuck, I want per-package eclasses and all those other goodies.

 2) EAPI in file extension
   - Allows changing global scope and the internal format of the ebuild
   a) .ebuild-eapi
 - ignored by current Portage
   b) .eapi.ebuild
 - current Portage does not work with this
   c) .eapi.new extension
 - ignored by current Portage

2a please, though .ebuild.eapi would be fine as well. My reasons are
mostly contained in Antarus' glep revision, and the fact that there have
been no real valid(IMO) objections.

 3) EAPI in locked down place in the ebuild
   - Allows changing global scope
   - EAPI can't be changed in an existing ebuild so the PM can trust
 the value in the cache
   - Does not allow changing versioning rules unless version becomes a
 normal metadata variable
 * Needs more accesses to cache as now you don't have to load older
   versions if the latest is not masked
   a) new extension
   b) new subdirectory like ebuilds/
   - we could drop extension all together so don't have to argue about
 it any more
   - more directory reads to get the list of ebuilds in a repository
   c) .ebuild in current directory
   - needs one year wait

These are all ugly.(c is the worst).

Oh, And I certainly hope this is not Democracy(you know what they say,
democracy is two wolves and a sheep deciding who to have for dinner)

Looking forward to the council meeting, where there will *hopefully* be
a decision.

Thomas
-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpFU0kxFHMxR.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)

2009-02-23 Thread Thomas Anderson
On Mon, Feb 23, 2009 at 02:21:33PM +0100, Luca Barbato wrote:
 Tiziano M??ller wrote:
 What is proposed in glep-55 seems to aim to solve both issues at the same 
 time (it isn't stated) by switching file extension every time the eapi is 
 changed. This is slightly against the principle of the least surprise and 
 apparently is disliked by enough people to lead the situation to be 
 discussed in the council.

 Instead of switching file extension every time the eapi is changed you
 could also increment it only when a new EAPI breaks sourcing the ebuild
 compared to the requirements of the prior EAPI.
 (This way you'd in fact split EAPI into a major- and a minor-version.)

 Makes you getting to have to do the two stage source again AND you get 
 another non obvious condition Should I bump the eapi internally or the 
 filename?

The glep is quite clear on that point.

 The main point again what is proposed in glep-55 is it that isn't invasive 
 and non-transparent to users and developers.

It's not all that invasive. All that changes is that the EAPI goes at
the end of the filename and you don't set it in the ebuild. Developers
should be able to keep up with this, and if a user asks it's easy enough
to say that it's a new version of ebuild, it has newer features see
www.blah.org/blah for details. And really, users already ask what EAPI
is so it's not that much headache.

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-


pgpb1wKek30va.pgp
Description: PGP signature


[gentoo-dev] prepalldocs is now banned

2009-02-13 Thread Thomas Anderson
Hi Everyone,

This is a note that in the council meeting on 02/12/2009 the
function 'prepalldocs' is banned for use in ebuilds with EAPIs 0 1
and 2. If you want some functionality from this function, please
propose a new function or clearly defined behavior for prepalldocs
for a *new* EAPI.

Regards,
Thomas Anderson

-- 
-
Thomas Anderson
Gentoo Developer
/
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
-




Re: [gentoo-dev] [RFC] bugs.g.o supported overlays should register

2009-01-05 Thread Thomas Anderson
On Sat, Jan 03, 2009 at 06:37:35PM +0100, Jeroen Roovers wrote:
 On Sat, 3 Jan 2009 13:56:15 +
 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote:
 
  What would really benefit Gentoo would be able to have the package
  manager aware of [...]
 
 I am sure you know of one that would provide... :)
 
 
  jer

I really don't think that's an issue. A good feature is a good feature
regardless of who thought up the idea or who implemented it first.
Please, let's not sidetrack the discussion of this idea with irrelevant
stuff.




Re: [gentoo-dev] [RFC] Moving HOMEPAGE out of ebuilds for the future

2008-11-30 Thread Thomas Anderson
On Sun, Nov 30, 2008 at 02:23:48PM +0100, Diego 'Flameeyes' Pettenò wrote:
 Please submit all comments, as long as they are not I don't like XML
 or XML is the wrong answer and similar since the point here is not to
 discuss the format of metadata but rather where to have it.

XML is the wrong answer. Sorry, but in this case, I'm arguing that this
should not be in metadata.xml but in,say, a per-package eclass. Also,
you don't have to worry about different HOMEPAGE's for different
versions/slots because you get that for free as soon as you decide to
use per-package/per-category eclasses. Really, we might as well use
per-package eclasses for this(not to mention the fact that they are
useful in other cases.)

Regards,
Thomas


pgp1XA7WdbcXk.pgp
Description: PGP signature


Re: [gentoo-dev] DEFAULT_* proposal

2008-11-09 Thread Thomas Anderson
On Sun, Nov 09, 2008 at 03:39:12PM +0300, Peter Volkov wrote:
 В Сбт, 08/11/2008 в 17:20 -0500, Thomas Anderson пишет:
  This is a reposting of a call for discussion on DEFAULT_* variables.
  The original discussion was at [1].
 1. Functions we have now are much more flexible then proposed arrays. Do
 I need to think of some example of code that is impossible to do with
 arrays but still possible with functions?

And more complex. Remember, I said that these proposals were not for
every case. Showing how it can't be used in one case says nothing about
it otherwise being used.

 2. Much simpler? No, it's not:
 
 (2.1) Such arrays do not not reduce the number of keys to be pressed.
 They require even more typing for small ebuilds [3] (example proposed by
 you, btw) and the only example which expose some improvement (presented
 by Santiago M. Mola[4]) shows that we still didn't learned how to use
 syntax we already have and (2.2) some extensions to the current syntax
 will just complicate things. Look if you remove $myconf variable from
 that ebuild[4], remove || die after econf and in EAPI=2 you can drop
 emake || die you'll see that the gain is small even for such medium size
 ebuild.
 At the same time this new syntax make some things worse:

Here's an example of how much gain there is with this approach:
http://tinyurl.com/6jj8a5

 1. it hides real code under this variables.
As mentioned, so do use_enable, use_with, emake(though these are
functions hiding code, DOCS. Hiding code is not always a bad thing.

 2. having variable like DEFAULT_RSC_PREPARE_PATCHES will promote bad
 practice of using patches instead of sed.

How so? We already have a ton of PATCHES variables as mentioned. How is
this standardization of what we already have going to promote bad
practices?

 3. SUCH_LONG_VARIABLES_IN_CAPS are always harder to read [5] and thus
 easier to do typo in them (like you did in DEFAULT_RSC_PREPARE_PATCHES,
 btw). (highlighting helps here but does not makes that variables easier
 to read or type in?)

Ok, so you could find a different name. The names aren't really
important. You could use USE_ENABLES and USE_WITHS and DEFAULT_PATCHES.

 4. it also conflates multiple concepts into a single variable name (the
 function name, whether it's USE-dependent, and how the configure flag is
 passed). (-- Donnie Berkholz [6])
 
 5. One of the great things about ebuilds is that they're very natural
 to write in most cases, if you can manage to build the program by hand.
 Raising this barrier of entry for questionable benefit seems like a bad 
 idea. (-- Donnie Berkholz [7])

No one is raising the barrier. People can continue to use use_enable and
use_with as they have for ages. The only thing that changes is that
ebuild devs now have another way(which is simpler from my experience and
that of others) to write ebuilds. Also, it's not that more

 
 So, why to reiterate this discussion without providing clear answer to
 the above concerns?
 
Because we came up with a more comprehensive proposal covering more
phase functions.
 
 At the same time default src_install is different proposal and having it
 implemented is a good idea.
 
 
 [1] http://article.gmane.org/gmane.linux.gentoo.devel/57990
 [2] http://article.gmane.org/gmane.linux.gentoo.devel/58728
 [3] http://thread.gmane.org/gmane.linux.gentoo.devel/57990
 [4] http://article.gmane.org/gmane.linux.gentoo.devel/57996
 [5] 
 http://archive.devwebpro.com/devwebpro-39-200305063ReasonsNotToUseUppercase.html
 [6] http://article.gmane.org/gmane.linux.gentoo.devel/58061
 [7] http://article.gmane.org/gmane.linux.gentoo.devel/58051
 
 -- 
 Peter.
 


pgp7EgxTeYlsl.pgp
Description: PGP signature


[gentoo-dev] DEFAULT_* proposal

2008-11-08 Thread Thomas Anderson
[RFC] Simplifying functions with variables and help from the PM

Hello All;
This is a reposting of a call for discussion on DEFAULT_* variables.
The original discussion was at [1]. The general idea is making the
default functions support some new variables so that they are more
flexible. 

Here are the function(in order of execution) changes I propose, but
let me first remind you that these changes are for the default
package manager implementation of the functions. Each proposal is
separate but it'd be nice if they all went in the same EAPI so it
doesn't get confusing.

src_prepare:
DEFAULT_RSC_PREPARE_PATCHES[]
This is a bash arrary list of patches to be applied to 
the
sources. This is implemented as PATCHES or similar 
variables
in a lot of eclasses like base, bzr, git, horde, kde, 
ruby,
ruby-gnome2, subversion and x-modular but they all have 
unneeded
differences. We'll need a function(say builtin_epatch, 
but 
better names are needed) in the PM to handle patching.

src_configure:
DEFAULT_SRC_CONFIGURE_USE_ENABLES[]
An array whose constants are passed as arguments to
`use_enable`. Each value of the array can have two 
parts.
DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'a52 a52dec' ) would
translate to $(use_enable a52 a52dec).

DEFAULT_SRC_CONFIGURE_USE_WITHS[]
Same as above, but s/enable/with/

DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS[]
Array of options to pass to econf

src_compile:
DEFAULT_SRC_COMPILE_PARAMS[]
Array of options to pass to emake

src_install:
All I want changed here is a variable for a list of 
extra docs to be
installed. This'll require a default function for
src_install and I propose:
src_install() {
emake -j1 install DESTDIR=${D} || die 
make install died
[[ -n ${DEFAULT_SRC_INSTALL_DOCS} ]]  
dodoc \
${DEFAULT_SRC_INSTALL_DOCS}
}
bug #33544 has more information on this topic, as does
tommy's recent thread on the subject of default 
src_install
function.

In my experience, these features greatly enhance ebuilds and make
the ebuilds simpler to write(before objecting to this point, read
the original thread[1] and/or use the feature), read, and maintain.

Also, one point I cannot stress enough is that this is not meant for
every ebuild but for the majority of simple cases.

Now, last time around, objections were made to the effect that the
src_configure proposal hides things in the PM which makes the
learning curve higer and hides things from the ebuild viewer. My
position on this is that it hides stuff in the same way that
`use_enable mp3` hides `use mp3  echo --enable-mp3 || echo
--disable-mp3`. In other words, not all cases where you move
thinsg to the PM are bad.

Credit for this idea goes to those who made the exheres package
format(used for the Exherbo linux distribution) and those who
participated in the discussion on bug #33544 over the past who knows
how many years.

Please discuss!
Thomas Anderson



[1]: http://article.gmane.org/gmane.linux.gentoo.devel/58038


pgpD38QL2RFMY.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Proposed change to base.eclass: EAPI-2 support

2008-11-05 Thread Thomas Anderson
On Wed, Nov 05, 2008 at 09:20:07PM +0100, Thomas Sachau wrote:
 Peter Alfredsen schrieb:
 Do you really think, a package that supports parallel make while compiling 
 fails support for
 parallel make support on install?

Happened for jabberd and jabberd2 to me.


pgpjnLZOswT2t.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/bti: bti-007.ebuild ChangeLog metadata.xml Manifest

2008-10-26 Thread Thomas Anderson
On Sun, Oct 26, 2008 at 05:22:26PM +, Greg Kroah-Hartman (gregkh) wrote:
 # Copyright 1999-2008 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/net-misc/bti/bti-007.ebuild,v 1.1 
 2008/10/26 17:22:26 gregkh Exp $
 
 RDEPEND=${DEPEND}
 
 src_compile() {
   emake || die emake failed
 }
This is the default src_compile.
 
 src_install() {
   doman bti.1
   dobin bti
   dodoc bti.example README RELEASE-NOTES
 }
You really should have some or all of these functions die on failure.
Since that's all the ebuild installs, the package is completely
nonfunctional if bti is not installed(I'd die on all three but you don't
have to die on the last one).


pgp9ukcpiV2Fc.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-misc/bti: bti-007.ebuild ChangeLog metadata.xml Manifest

2008-10-26 Thread Thomas Anderson
On Sun, Oct 26, 2008 at 02:58:02PM -0700, Greg KH wrote:
 On Sun, Oct 26, 2008 at 01:36:29PM -0400, Thomas Anderson wrote:
  On Sun, Oct 26, 2008 at 05:22:26PM +, Greg Kroah-Hartman (gregkh) wrote:
   src_install() {
 doman bti.1
 dobin bti
 dodoc bti.example README RELEASE-NOTES
   }
  You really should have some or all of these functions die on failure.
 
 Why would any of these fail if the src_compile succeeded?
Succeeded and Not error out are different. Src_compile could not
error out but still not produce the executables/produce an executable
with a different name. Either way you end up with a broken installation
of bti.
 And, for some reason I thought that the default was that if there was an
 error in them, they would die on their own.  Is that not the case?
No, they don't die on their own. As far as I know, very few ebuild
functions do. Econf does, and epatch does as well. I'll look into
writing up a list of which functions die and which don't though, for
convenience.


pgptdpnKyJ2V9.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Testing is not a valid reason to package.mask

2008-10-04 Thread Thomas Anderson
On Fri, Oct 03, 2008 at 11:44:10PM -0600, Ryan Hill wrote:
 On Thu, 2 Oct 2008 22:24:35 +0200
 Jeroen Roovers [EMAIL PROTECTED] wrote:
 
  Please people,
  
  
 if you want to get something tested, then don't mask it.
 
 So, no, I'll continue using package.mask for testing just
 as it always has been.  Sorry.

++, especially on unleashing broken stuff to users.


pgpuWmcecRWqF.pgp
Description: PGP signature


Re: [gentoo-dev] Re: Default src_install for EAPI-2 or following EAPI

2008-09-21 Thread Thomas Anderson
On Sun, Sep 21, 2008 at 08:18:05AM +0200, Vaeth wrote:
 Steve Long wrote:
 
  Thomas Sachau wrote: [...]
 
   [[ -n ${DOCS} ]]  dodoc ${DOCS}
 [...]
  
  It might be wise to use an array for DOCS there
 
 Since I have now seen suggestions for using arrays unnecessarily
 at least twice (see also
   [RFC] Ability to pass arguments to src_configure/src_compile
 but I am only speaking about the usage of _arrays_ here),

Er, how were arrays use unnecessarily in the src_configure/src_compile
case?


pgpUcAcV1s0CV.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] EAPI 2 Draft

2008-09-06 Thread Thomas Anderson
On Sat, Sep 06, 2008 at 12:43:12PM +0100, Steve Long wrote:
 Christian Faulhammer wrote:
 
  Zac Medico [EMAIL PROTECTED]:
  Both approaches are essentially equivalent but it's a little simpler
  for ebuild writer if they don't have to customize the output file
  name.
  
   One needs exceptions for all kind of systems, for example I had to
  workaround Trac which adds ?format=raw to a tarball URI.  There seems
  to be a solution in Trac as the guys from fedarahosted fixed the two I
  needed (tmpwatch, mlocate).  So the - operator is quite useful and I
  agree with David that the functionality is doubled.
  
 Clearly src-uri transformation is useful. Others have given examples of how
 it would be useful to an eclass. Irrespective of how the actual transform
 is done in the ;sf=tbz2 case, both _are_ valid use-cases.

Sure they may be valid use cases, but the issue is whether the
;sf=tar.bz2 code is duplicated from '-'. I don't see any reason why you
can't use '-' to handle ;sf=tbz2, so they are duplicated. Since '-'
can be used in more circumstances(SRC_URI=http://foo.com/2.3/foo.bz2
- ${P}.tar.bz2 comes to mind), we don't need ;sf=tbz2.


pgpD0tA0gVKlo.pgp
Description: PGP signature


[gentoo-dev] [RFC] Ability to pass arguments to src_configure/src_compile

2008-09-06 Thread Thomas Anderson
Hi,
Currently we have a lot of:
src_configure() {
econf $(use_enable dvdr) \
$(use_with ipv6 ssl) \
--with-system-zlib
}

Introducing(Idea shamelessly taken from Exherbo):
DEFAULT_SRC_CONFIGURE_USE_{WITHS,ENABLES}
DEFAULT_SRc_CONFIGURE_EXTRA_PARAMS

The code from above could be rewritten like so:

DEFAULT_SRC_CONFIGURE_USE_ENABLES=( 'dvdr' )
DEFAULT_SRC_CONFIGURE_USE_WITHS=( 'ipv6 ssl' )
DEFAULT_SRC_CONFIGURE_EXTRA_PARAMS=( '--with-system-zlib' )

That's much simpler. 

Also taken from Exherbo, DEFAULT_SRC_COMPILE_PARAMS could be used to 
append parameters to emake like so:

src_compile() {
emake buildtarget
}

which would be replaced by:
DEFAULT_SRC_COMPILE_PARAMS=( 'buildtarget' )

This was originally proposed in bug #230725[1]

Regards,
Thomas

[1] https://bugs.gentoo.org/show_bug.cgi?id=230725


pgp7YUHyykivk.pgp
Description: PGP signature


Re: [gentoo-dev] Re: [RFC] What features should be included in EAPI 2?

2008-08-21 Thread Thomas Anderson
On Tue, Aug 19, 2008 at 11:31:17PM +0530, Arun Raghavan wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Ciaran McCreesh wrote:
 [...]
  The benefit is that it's a logically separate action, and will avoid
  all the silliness of people repeatedly changing their minds about
  which phase should do the eautoreconf calls and so on.
 
 a) Is this really an issue for maintainers?
As someone who has worked with exheres, I very much want this phase for
EAPI 2. It makes things simpler and more logical. Why should patching be
done in _unpack? It shouldn't, and that's a reason why _prepare should
be added.
 b) Does it really matter?
To me, yes


pgpaXQSYQmSiY.pgp
Description: PGP signature


Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins

2008-08-08 Thread Thomas Anderson
On Wed, Aug 06, 2008 at 02:18:05PM -0700, Robin H. Johnson wrote:
 Getting the bot out there
 -
 If you would like to have the new bot in your #gentoo-* channel, would
 each channel founder/leader please respond to this thread, stating the
 channel name, and that they are the contact for any problems/troubles.

I'm certainly not a founder nor a leader, but I think I speak for all of
us in the amd64 team that we would like a bot to tell us about bugs.

so: 
#gentoo-amd64-dev 
#gentoo-amd64

Thanks.


pgpccMBtrkBYb.pgp
Description: PGP signature


[gentoo-dev] [RFC] default_* functions

2008-08-07 Thread Thomas Anderson
Hi,

Currently we have default_* functions implemented in
portage(paludis has these too)
which allow the default implementation of a particular phase
to be called. Another handy function in the default_* series is
function 'default' which simply calls the default function for
whatever phase you're in. The 'default' function patch is probably
before you read this, and a release(2.2_rc7) will soon follow.

Zac has said this release will have support for these functions in
EAPI 2_pre2. Discuss!


pgpjbN00ADzUE.pgp
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2008-07-20 Thread Thomas Anderson
On Sun, Jul 20, 2008 at 08:44:24AM +0200, Christian Faulhammer wrote:
   app-admin/tmpwatch -- low maintenance
 
I can take this one.

   dev-cpp/libthrowable,
   app-portage/gatt -- very cooperative upstream for both (mlangc for
 both)
 

I can also take these two as well, as I use them for arch testing.


pgp3tCSB9jUdf.pgp
Description: PGP signature


Re: [gentoo-dev] RFC: 0-day bump requests

2008-07-03 Thread Thomas Anderson
On Fri, Jul 04, 2008 at 12:26:13AM +0100, Tony Chainsaw Vroon wrote:
  2) If you had your way, would you discourage users from filing early
  version bump requests?
 Just an idea:
 How about a metadata.xml tag that indicates whether early bump requests are 
 welcome?
 It's more of an individual developer preference, but that seems the right 
 place for it.
 
 Regards,
 Tony V.

I think Tony's metadata.xml idea is perhaps the proper way to handle
this issue. 

As for your questions, I like getting bump requests as soon as possible, as I 
can't check
upstream's website every day or two. One thing to watch out for is
a huge amount duplicates.


pgpALlD7eNq3X.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/quassel: ChangeLog quassel-9999-r1.ebuild quassel-0.2.0_rc1.ebuild quassel-0.2.9999.ebuild

2008-07-02 Thread Thomas Anderson
In-Reply-To: [EMAIL PROTECTED]
   Add missing eutils inherit for the non-git ebuilds as otherwise it seems to 
 be failing.
   (Portage version: 2.2_rc1/cvs/Linux 2.6.25-gentoo-r4 x86_64)
 
The reason it's failing is because you have things after the . You
can do this:

if [[ ${PV} == ** ]]; then
inherit git

instead of:
  if [[ ${PV} == * ]]; then
   inherit git

Doing it my way doesn't fail for, say, -r1

Regards,
Thomas


pgp0Mzp7grOpD.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/opencv: opencv-1.0.0.ebuild metadata.xml Manifest ChangeLog

2008-06-18 Thread Thomas Anderson
On Wed, Jun 18, 2008 at 05:24:34AM +, Josh Glover (jmglov) wrote:
 LICENSE=Intel
Check configure output, GPL-2 license is enabled if v4l and/or xine USE
flags are on.

 SLOT=0
 KEYWORDS=~x86
 IUSE=ffmpeg gtk ieee1394 python swig v4l v4l2 xine
 
 DEPEND=
   dev-util/pkgconfig

With the code below, pkgconfig ends up in RDEPEND, and we don't want
that. Try using COMMON_DEPEND for things like this.
   media-libs/jasper
   media-libs/jpeg
   media-libs/libpng
   media-libs/tiff
   sys-libs/zlib
   ffmpeg?   ( =media-video/ffmpeg-0.4.9 )
   ieee1394? ( media-libs/libdc1394   )
Check configure output, this package needs a version of libdc1394 in
SLOT 1.
   ieee1394? ( sys-libs/libraw1394)
Check configure output, this package needs a version =1.2.0
   gtk?  ( =x11-libs/gtk+-2  )
This could be better done with SLOT dependencies.
   python?   ( =dev-lang/python-2.3  )
   swig? ( dev-lang/swig  )
Check configure output, this package needs swig =1.3.30
   xine? ( media-libs/xine-lib)
 
 RDEPEND=${DEPEND}
 

You're missing OpenEXR as a runtime/buildtime dependency
 src_compile() {
   local myconf=--without-quicktime
 
   if   use ffmpeg ; then
   ## TODO: jmglov 2008/06/18
   ## Remove this junk once bug # 227975 is resolved
   ewarn ${PN} currently will not build with ffmpeg support
   ewarn Please enable the 'xine' USE flag instead
   ewarn Working on this in bug # 227975
   die configuration failed; see above
   ## TODO: jmglov 2008/06/18

You can use.mask ffmpeg for the time being, so users don't get killed by
this in the meantime, before you pull my patches from the science
overlay
 
   myconf=${myconf} --with-ffmpeg --without-xine
   elif use xine   ; then
   myconf=${myconf} --with-xine --without-ffmpeg
   else
   die You must set one of the 'ffmpeg' or 'xine' USE flags
   fi
That doesn't seem right, it's working in the science overlay with
neither of them set.
   myconf=${myconf} $(use_with ieee1394 1394libs)
   myconf=${myconf} $(use_with python)
   myconf=${myconf} $(use_with swig)
   myconf=${myconf} $(use_with v4l)
 
   econf ${myconf} || die econf failed
 
   emake || die emake failed
 }
Beware of automagic dependencies, they're fixed in the science overlay!
 
 
 
 1.1  media-libs/opencv/metadata.xml
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/opencv/metadata.xml?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/opencv/metadata.xml?rev=1.1content-type=text/plain
 
 Index: metadata.xml
 ===
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd;
 pkgmetadata
 maintainer
 email[EMAIL PROTECTED]/email
 nameJosh Glover/name
 /maintainer
 longdescriptionOpenCV (Open Source Computer Vision) is a library of 
 programming functions mainly aimed at real time computer vision.
 
 Example applications of the OpenCV library are Human-Computer Interaction 
 (HCI); Object Identification, Segmentation and Recognition; Face Recognition; 
 Gesture Recognition; Motion Tracking, Ego Motion, Motion Understanding; 
 Structure From Motion (SFM); and Mobile Robotics./longdescription
 /pkgmetadata
 
 
 
 1.1  media-libs/opencv/Manifest
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/opencv/Manifest?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/opencv/Manifest?rev=1.1content-type=text/plain
 
 Index: Manifest
 ===
 DIST opencv-1.0.0.tar.gz 11146334 RMD160 
 f041798ea63101b90e945957e0d0ad3f7497dcd4 SHA1 
 c7dd500703b0060cedfa049fcb33de0846e631fb SHA256 
 3a6ee888e4dd4ab7f2bc80d046688c099c6a95d1267af554b7c8f1543b66f21e
 EBUILD opencv-1.0.0.ebuild 1687 RMD160 
 84b439cc4a0bc06723b3ccec129cd84071e82e48 SHA1 
 d296fb7057e192ee0c0b424a9577cb25f79dca0e SHA256 
 aa1521a657e1fe352a596d261a24497ea012962aac03d2eba6abcfa22fa01b6f
 MISC ChangeLog 258 RMD160 8c6fcc66840ee3c1aa26e27c5bc640e7d63ed85b SHA1 
 4558d511042c00854b070b236424da03a90b1c37 SHA256 
 52d247930ecb833cd9f34552c2aa8f931435578c0081e7a00fd56dece8318ce1
 MISC metadata.xml 652 RMD160 5cfb86ff65264086bc032c406763d3cc46b075d2 SHA1 
 771ee2dc24641518bbacc47bbffa356d0c071a35 SHA256 
 b63ce92a359d882b519ef92ef358a73ce854bd875e19c283c72217b0d7965bdc
 
 
 
 1.1  media-libs/opencv/ChangeLog
 
 file : 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/opencv/ChangeLog?rev=1.1view=markup
 plain: 
 http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-libs/opencv/ChangeLog?rev=1.1content-type=text/plain
 
 Index: ChangeLog
 

Re: [gentoo-dev] eapi1 bug/pkgcore sucks thread [was EAPI-2 - Let's get it started]

2008-06-12 Thread Thomas Anderson
On Wed, Jun 11, 2008 at 07:16:05PM -0700, Brian Harring wrote:
 On Wed, Jun 11, 2008 at 07:00:16PM +0100, David Leverton wrote:
  On Thursday 12 June 2008 02:46:03 Jim Ramsay wrote:
   David Leverton [EMAIL PROTECTED] wrote:
Since at least one ebuild has already been modified specifically to
work around the bug, I'd say it's pretty real.
  
   For those of us trying to play along at home, which one is this?
  
  http://tinyurl.com/4w4t69
 
 Few things I'll note about this stupid, stupid mess- looks of it, 
 paludis folk have known about this for a while.  In other words, folk 
 bitching about 'improving' QA intentionally sat on a bug for the sake 
 of mocking, bug which according to them ebuild devs have supposedly 
 worked around (yet to see it, but it's viable).
 
 Useful to the whole, I'm sure.  Same folk in control of PMS for those 
 playing the home game, politics over QA seemingly.
 
 So what was the bug?  Aside from having to walk the full eapi-1 bugs,
 (ebuild referenced wasn't of use), majority of which actually *is* 
 tested in pkgcore (unlike portage which makes one wonder why pkgcore 
 is targeted), the fault is a simple defaulting of an unset var being 
 missed in implementing an undocumented spec (honestly, where is eapi1 
 spec?).
 
 Literally, the BS of the last day all comes down to inability to state 
 the following:
 
 === modified file 'pkgcore/bin/ebuild-env/ebuild-functions.sh'
 --- pkgcore/bin/ebuild-env/ebuild-functions.sh2007-11-12 01:17:24 
 +
 +++ pkgcore/bin/ebuild-env/ebuild-functions.sh2008-06-11 22:24:16 
 +
 @@ -236,7 +236,7 @@ src_compile
  {
  if [ ${EAPI:-0} == 0 ] ; then
  [ -x ./configure ]  econf
 -elif [ -x ${ECONF_SOURCE}/configure ]; then
 +elif [ -x ${ECONF_SOURCE:-.}/configure ]; then
  econf || die econf failed
  fi
  if [ -f Makefile ] || [ -f GNUmakefile ] || [ -f makefile ]; then
 


I'm not quite sure how you're trying to present this, but are you really
trying to say that EAPI 1 isn't documented? I myself found this in
pms.pdf in 2 minutes(it's section 10.1.3). I wouldn't exactly say it's
because it was missed in implementing an undocumented spec.


pgpcHKJFXxnuK.pgp
Description: PGP signature


Re: [gentoo-dev] One-Day Gentoo Council Reminder for June

2008-06-12 Thread Thomas Anderson
On Thu, Jun 12, 2008 at 11:11:51PM +0100, George Prowse wrote:
 Ciaran McCreesh wrote:
 On Thu, 12 Jun 2008 15:34:56 -0400
 Doug Goldstein [EMAIL PROTECTED] wrote:
 I'd honestly like to see an official PMS project page i.e. 
 http://www.gentoo.org/proj/en/pms/
 There's http://www.gentoo.org/proj/en/qa/pms.xml . Unfortunately, rane
 decided to go and vandalise it for some reason and no-one working on
 PMS appears to have commit access to it...
 I would like to comment that the wording on that page is unacceptable.

 With the advent of alternative package managers, this ill-defined standard 
 is no longer sufficient... makes it sound like the previous work that was 
 done was by idiots.
 -- 
 gentoo-dev@lists.gentoo.org mailing list

That says nothing about the previous state of the portage. It only says
the standard wasn't well-defined before PMS.

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] EAPI-2 - Let's get it started

2008-06-11 Thread Thomas Anderson
On Wed, Jun 11, 2008 at 08:23:59AM +0100, Richard Brown wrote:
 Also, I think you seem to be suggesting that gentoo is so well tested
 that once something's marked stable, there's no point in testing it.

A very good point. Just last week the *stable* perl cairo bindings were
broken by a x11-libs/cairo bump. We caught this however and noticed that
the new perl cairo bindings worked. Those were then stabilized at the
same time and users now have a working cairo.

What would have happened if that hadn't happened? Any package that
depended on dev-perl/Cairo would've been broken.

The lesson to learn is that once something is stable doesn't mean it's
always stable. If a user finds out that way and files a bug, chances are
greater that he'll get a dev-perl/Cairo that works with the new cairo
version soon, rather than a dev-perl/Cairo version that breaks
immediately.

What would you rather have?


pgpbdD6ZaLPYT.pgp
Description: PGP signature


Re: [gentoo-dev] A few questions to our nominees

2008-06-09 Thread Thomas Anderson
On Mon, Jun 09, 2008 at 01:00:52PM +0200, Fabian Groffen wrote:
 On 09-06-2008 11:49:35 +0200, Luca Barbato wrote:
  Ciaran McCreesh wrote:
  On Mon, 09 Jun 2008 10:50:11 +0200
  Luca Barbato [EMAIL PROTECTED] wrote:
  So how, specifically, is PMS wrongly written, and why hasn't
  anyone who thinks so bothered to provide details?
  - rewrite it as an rfc using a markup among xmlrfc, docbook, guidexml.
 
  What technical reason is there to use a markup that's more work for
  those of us doing the writing? Writing XML is a huge pain in the ass
  compared to latex.
 
  More people can understand those markups, they are consistent with the  
  gentoo documentation, they look better on screen than on paper, tex is a  
  great typesetting markup to write academic books. Right tool for the  
  right task. It address the problem PMS is anything but accessible
 
 I think this is a bit of a pointless discussion.  If people insist on
 reading the source and are scared of LaTeX, then the same can happen for
 any other language.  PMS is available as pdf (or can easily being made
 by typing `make`), which is readable IMO, and one could always try how
 far one gets with a LaTeX-XML translator and XSLT transformations
 afterwards.  Still, what is the point of requiring language X over Y?  I
 for one prefer LaTeX over any of the formats you mentioned before, but
 that should not be of any value here.

++

I personally have had no problems reading and/or understanding PMS, and
I've had to reference a fair bit of it. I'd like to hear exactly who has
problems with what sections and how to fix that. 

As Fabian said it really isn't a matter of We like XML better than LaTeX! 
It's not those people's
perogative. The people who wrote PMS should be able to make the decision
for themselves(as they will be maintaining it) as to what language to
use. If they use LaTeX, more power to them, it's what enables them to do
their job in the easiest way. You don't *have* to read PMS in LaTeX,
which by the way makes my eyes bleed somewhat, you can read it in a very
well done PDF.

Regards,
Thomas


pgphJhgm1mXuT.pgp
Description: PGP signature


Re: [gentoo-dev] A few questions to our nominees

2008-06-09 Thread Thomas Anderson
On Mon, Jun 09, 2008 at 01:26:53PM +0100, Ciaran McCreesh wrote:
 On Mon, 09 Jun 2008 14:18:01 +0200
 Luca Barbato [EMAIL PROTECTED] wrote:
   The people who wrote PMS should be able to make the decision
   for themselves(as they will be maintaining it) as to what language
   to use.
  
  The main point being using latex prevents people from modify it.
 
 Are you seriously suggesting that hypothetical contributions we might
 receive from people who hypothetically might contribute if only we used
 XML instead of Latex outweigh all the extra work XML requires?

Right, and though I don't understand LaTeX all that well, it wasn't too
difficult to stop me from writing the spec for one function. I
personally dislike XML even more than LaTeX, but that shouldn't stop
those who wrote it from using it.


pgpNVKiLPgC4x.pgp
Description: PGP signature


Re: [gentoo-dev] Packages up for grabs

2008-05-28 Thread Thomas Anderson
On Wed, May 28, 2008 at 09:03:33AM +0200, Krzysiek Pawlik wrote:
  * net-im/jabberd  net-im/jabberd2 - thanks to work from Marko Durkovic 
 both are easy to maintain
I can take jabberd(maybe jabberd2 too) by proxy, until I finish my
quizzes.


-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] Early stabilisation

2008-04-17 Thread Thomas Anderson
On Thu, Apr 17, 2008 at 09:40:22PM +0200, Santiago M. Mola wrote:
 On Thu, Apr 17, 2008 at 2:33 PM, Samuli Suominen [EMAIL PROTECTED] wrote:
  Thu, 17 Apr 2008 09:43:59 +0200
   Vlastimil Babka [EMAIL PROTECTED] kirjoitti:
 
Okay. So we can just agree it's better if the maintainer tells his
reasons when opening the bug, to spare the later clarifications?
 
   It works. Do it.
 
 
 While I agree with you, and I think we are free to request
 stabilization before the 30 days window, I also love when people give
 details about the stabilization and not just a do it.
 
 Emacs team's test plans [1] are the better example. Thanks to them
 I'm able to save a _lot_ of time figuring out how a package works and
 which features should test.
 
 Some details about changes since last stable are usually useful too.
 In latest wgetpaste stabilization [2] we are told that this is a
 trivial bugfix release fixing osl support, so we can just test osl
 support and skip most of other tests.
++, this really helps the testing get done quicker.
 Also, when a program needs a sample file with some obscure format, I
 really appreciate when maintainers give a URL to a sample file so I
 don't need to search for suitable files and can strictly focus on
 testing.
Agreed, the fonts team link to a page using the fonts in the package,
which makes the package trivial to test. ++ to them.
 
 Of course, everyone could continue with the do it style, but keep in
 mind that adding info like I described above can save a lot of AT work
 and, as a result, make stabilization process faster.
Most of the time I see the doit bugs is when the package has broad
uses(i.e. coreutils and most things owned by base-system), and I
generally don't have a problem when the package has many various uses
that all had changes.
 [1] http://overlays.gentoo.org/proj/emacs/wiki/test%20plans
 [2] http://bugs.gentoo.org/show_bug.cgi?id=211894
 
 
 Regards,
 -- 
 Santiago M. Mola
 Jabber ID: [EMAIL PROTECTED]
 -- 
 gentoo-dev@lists.gentoo.org mailing list


pgpTCFPZza2v9.pgp
Description: PGP signature


[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-dialup/freeradius: freeradius-2.0.3.ebuild

2008-04-13 Thread Thomas Anderson
On Sun, Apr 13, 2008 at 05:41:18PM +, Alin Nastac (mrness) wrote:
 mrness  08/04/13 17:41:18
 
   Modified: ChangeLog
   Added:freeradius-2.0.3.ebuild
   Log:
   Version bump.
   (Portage version: 2.1.4.4)

 src_install() {
   mv ${D}/usr/share/doc/${PN} ${D}/usr/share/doc/${PF}
   gzip -f -9 ${D}/usr/share/doc/${PF}/{rfc/*.txt,*}
Doesn't this gzip command rather defeat the purpose of $PORTAGE_COMPRESS
and $PORTAGE_COMPRESS_FLAGS?

It seems this might work better:

ecompress ${D}/usr/share/doc/${PF}/{rfc/*.txt,*}

This way a user can opt to use bzip2,lzma, or no compression at all.
 -- 
 [EMAIL PROTECTED] mailing list
 


pgpsz1B3cdgOT.pgp
Description: PGP signature


Re: [gentoo-dev] Monthly Gentoo Council Reminder for April

2008-04-03 Thread Thomas Anderson
On 11:35 Thu 03 Apr , Jorge Manuel B. S. Vicetto wrote:
 Petteri R??ty wrote:
 Jorge Manuel B. S. Vicetto kirjoitti:
 Petteri R??ty wrote:


 As others have commented, I don't agree with this point. Also, you're 
 forgetting we have quite a few people working on this project and that we 
 have many different roles.
  
 And you are assuming that undertakers wouldn't check their role before 
 acting.

 I read it as a rule to drop developers. If we're only talking about it 
 raising a warning to undertakers so they can check the dev status, then I 
 don't have a problem with the proposal.

 Recalling previous discussions about work on gentoo and some of the 
 existing roles, what will you do to AT folks, release members or QA 
 members? Are they also obliged to do a weekly commit to keep their 
 privileges?
 AT folks aren't devs and see above.

 To be clear, I didn't meant arch testers but people that do keywords for 
 arch teams.

Actually, 'AT' can refer to either arch teams or Arch Testers, but given
the fact that he was referring to those people with commit access, it
should be obvious he meant 'Arch Teams'.

Thomas

-- 
gentoo-dev@lists.gentoo.org mailing list



Re: [gentoo-dev] New keyword monkey: Kenneth Prug (ken69267)

2008-03-08 Thread Thomas Anderson
On Saturday 08 March 2008 12:30:17 Petteri Räty wrote:
 Joining us from the zoos of Florida, we have Kenneth keninsert random
 numbers here Prugh. Ken did such a fine job testing all those random
 packages for amd64 that it will be the sole purpose of his life from now
 on. He tells me his hobby is to learn new programming languages so I
 guess he doesn't get bored easily. Time for the usual spanking everyone.

 Regards,
 Petteri


use adjutrix || die failee!

And goodbye most active Arch Tester! 

:)


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-05 Thread Thomas Anderson
On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
 Thomas Anderson kirjoitti:
  Please elaborate on how a full.fledged developer would differ from a
  package maintainer technically. What requirements and/or
  priviledges do you think could be reduced?
 
  Marius
 
  Perhaps there could be some honor code system at least, where the package
  maintainer would be restricted to their area of maintainership.

 This is the current situation.

 Regards,
 Petteri

Exactly, only the package maintainers wouldn't have everything that a full 
dev would have...


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-05 Thread Thomas Anderson
On Wednesday 05 March 2008 14:59:55 Doug Goldstein wrote:
 Thomas Anderson wrote:
  On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
  Thomas Anderson kirjoitti:
  Please elaborate on how a full.fledged developer would differ from a
  package maintainer technically. What requirements and/or
  priviledges do you think could be reduced?
 
  Marius
 
  Perhaps there could be some honor code system at least, where the
  package maintainer would be restricted to their area of maintainership.
 
  This is the current situation.
 
  Regards,
  Petteri
 
  Exactly, only the package maintainers wouldn't have everything that a
  full dev would have...

 What exactly wouldn't they get? What would differ them from Arch Testers?

Arch Testers don't have tree access. This proposal gives the package 
maintainer the ability to commit their changes.

-- 
Taylor and Anderson, Metropolitan prosecutors. Commit a crime? See you in 
court


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-05 Thread Thomas Anderson
On Wednesday 05 March 2008 14:59:55 Doug Goldstein wrote:
 Thomas Anderson wrote:
  On Wednesday 05 March 2008 14:41:32 Petteri Räty wrote:
  Thomas Anderson kirjoitti:
  Please elaborate on how a full.fledged developer would differ from a
  package maintainer technically. What requirements and/or
  priviledges do you think could be reduced?
 
  Marius
 
  Perhaps there could be some honor code system at least, where the
  package maintainer would be restricted to their area of maintainership.
 
  This is the current situation.
 
  Regards,
  Petteri
 
  Exactly, only the package maintainers wouldn't have everything that a
  full dev would have...

 What exactly wouldn't they get? What would differ them from Arch Testers?

Arch Testers don't have tree access. This proposal gives the package 
maintainer the ability to commit their changes.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Monthly Gentoo Council Reminder for March

2008-03-05 Thread Thomas Anderson
On Wednesday 05 March 2008 16:05:09 Petteri Räty wrote:
 Thomas Anderson kirjoitti:
  Arch Testers don't have tree access. This proposal gives the package
  maintainer the ability to commit their changes.

 How would you ensure ebuild quality for these package maintainers?

 Regards,
 Petteri

Maybe a small review board of 3-4 people to make sure that all new packages 
meet the requirements in the devmanual? Just an idea, maybe not the best.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Keyword request interface (SoC candidate?)

2008-02-29 Thread Thomas Anderson
On Friday 29 February 2008 13:13:16 Richard Freeman wrote:
 Rémi Cardona wrote:
  +1 on that idea, using bugzilla with an external tool for keyword
  requests is a good idea.
 
  The tool could do bugzilla research to see if the keyword has already
  been requested and point the user to the corresponding bug report,
  hopefully limiting the number of dupes.

 ++

 It would still be nice to have better status tracking in bugzilla - some
 way for ATs to officially mark that stuff is tested in a way that can be
 easily queried (so that ATs can find stuff that isn't tested, and devs
 can find stuff that has been).  The issue about hard-to-test packages is
 really a separate one, but one that could use a solution...

Definitely. I find it very annoying searching through bugzilla looking for 
things that other Arch Testers haven't tested. On the other hand, after a 
while you start to remember which bugs haven't been tested(at least if you 
are on an arch with 150 bugs). Barring that case, such a system would be 
very nice.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] New developer: Bo Ørsted Andresen (zlin)

2008-02-28 Thread Thomas Anderson
On Thursday 28 February 2008 07:28:27 Rémi Cardona wrote:
 Petteri Räty a écrit :
  He has been breaking the tree for a while now but as Calchan has been
  having availability problems I get to insult him a little bit later than
  usual. Bo hails from Aalborg, Denmark. He studies to become a control
  engineer. On the Gentoo side he is one of the people who enabled KDE4
  coming to our main tree via contributing to their overlays.

 Boo! Hiss!

 Just kidding ;)

 Anyway, Welcome to our crazy team and have fun !

 Cheers

 --
 Rémi Cardona
 LRI, INRIA
 [EMAIL PROTECTED]
 [EMAIL PROTECTED]

Even more on-topic, Welcome to the Krazy team! ;-)

-- 
Taylor and Anderson, Metropolitan prosecutors. Commit a crime? See you in 
court


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] RFC: Adding available as a mentor bit to LDAP

2008-02-11 Thread Thomas Anderson
On Monday 11 February 2008 14:47:35 Petteri Räty wrote:
 Often we have someone wanting to become a dev and we need a to find a
 mentor for him. What do you think about adding a status bit to LDAP that
 would mark you as available for mentoring? Recruiters could then use
 this info to forward people to these developers.

 Regards,
 Petteri

While I certainly agree that such a status bit is useful, there is perhaps 
some more stuff that could be added. To be more exact, it might be useful to 
have, say, a person who is willing to mentor someone interested in general 
ebuilds/media-related stuff/fonts/X11. In this way, it is more obvious who to 
contact other than a list of developers marked as 'available'.

Thanks,
Thomas


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays

2008-01-20 Thread Thomas Anderson
On Thursday 17 January 2008 16:47:28 Robin H. Johnson wrote:
 Hi folks,

 Infra is working on a bunch of things lately, and there are going to be
 changes or brief outages for the following services (this is pretty much
 the order they are being worked on).

 anonvcs.gentoo.org: anoncvs, anonsvn, anongit
 - Moving between machines
 - Anonymous SVN is changing from http:// to svn:// [1]
 Did this plan include disabling of compression for anoncvs? I noticed my 
compression-enabled cvs up's were spewing out information about 
gzip-file-contents not being supported. This only started happening within 
the past few days, so it probably happened with this switch(assuming the 
switch happened already ;) ).

Regards,
Thomas
-- 
2.6.23-gentoo-r3


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)

2007-12-21 Thread Thomas Anderson
On Friday 21 December 2007 08:43:43 Richard Freeman wrote:
 Ciaran McCreesh wrote:
  Please don't comment any further until you understand how this whole
  thing works.
 CON:
 Yet another value to be parsed out of an increasingly-complex filename.
 Doesn't look pretty  :)
Taste is a matter of opinion. I happen to like eapi-1 in the filename so I 
know a bit about the ebuild before looking through its contents.
 Makes a low-level detail more visible to users.
 You can't make a wild change to how EAPIs are specified - since old PMs
 will expect it to be in the filename in a particular format.
This isn't a CON, it is actually a PRO because old PMs won't recognize the new 
format and everyone will be happy. (something not so easy with the other 
solutions.)


-- 
2.6.23-gentoo-r3


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: EAPI placement

2007-12-11 Thread Thomas Anderson
On Tuesday 11 December 2007 18:21:31 Markus Ullmann wrote:
 Doug Klima schrieb:
  Cardoe zmedico: what if I have EAPI=2 above the inherit but an eclass
  has EAPI=1

 if an eclass sets EAPI, then the ebuild shouldn't... make it two
 eclasses if needed or plain bump them if really really needed.

 Greetz
 Jokey

That doesn't sound right. What happens if the eclass sets an EAPI(say 1), but 
you need to use say X feature(which is in EAPI 2). By what you said, this 
would prevent the ebuild from using the features in EAPI 2. It also isn't 
smart to bump eclasses' EAPI--EAPI should be set to the lowest common 
denominator that that feature being used is in.

If that made sense ;)

-- 
2.6.23-gentoo-r3


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] X drivers up for grabs

2007-12-04 Thread Thomas Anderson
On Monday 03 December 2007 20:29:20 Donnie Berkholz wrote:
   via

While I can't maintain this(no gentoo-x86/ access) I can test it if no one is 
able to.
-- 
2.6.23-gentoo-r3


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Gentoo Arch Testing Tool

2007-10-13 Thread Thomas Anderson
On Wednesday 10 October 2007 04:54:13 Christian Faulhammer wrote:
 Hi,

 all arch devs interested in above tool (app-portage/gatt-svn), I wrote
 a little introduction for it.  See Planet.

 V-Li

From the Blog Post:

1. emerge the package with different USE flags

Tasks 1, 2, 4 and 5 can be automated, while 3 needs some experience and 
brain-work.

Gentoo Arch Testing Tool (Gatt) which comes in very handy at least in phase 1.

However, the current gatt can't merge the packages with different USE flags 
yet(--with-use). Just thought I'd point that out.

Thanks for the great tool!
-- 
2.6.22-gentoo-r8


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] controlling src_test

2007-10-04 Thread Thomas Anderson
On Thursday 04 October 2007 09:36:29 Doug Goldstein wrote:
 Ravi Pinjala wrote:
  Ryan Hill wrote:
   There are several packages in portage (and even in base-system) that
 
  fail
 
   in src_test when userpriv/usersandbox is enabled or disabled.  That
 
  is, some
 
   testsuites fail when run as root and some fail if not run as root.
  
   I'd like a simple consistent way to mark or handle these packages
 
  without
 
   disabling tests altogether (RESTRICT=test).  As mentioned recently,
 
  checking
 
   ${FEATURES} in an ebuild is frowned upon, and it doesn't seem right
 
  to handle
 
   this on a per-ebuild basis.  How would something like this best be
 
  implemented?
 
   A split up RESTRICT (test_userpriv/test_nouserpriv)?  test.eclass?
 
  Something
 
   else?  Looking at the bigger picture, are there any other situations
 
  where
 
   finer-grained control over the test system would be helpful?
  
   While I'm on the subject, I also thought it would be cool to have
 
  the option to
 
   not die on a src_test failure, but instead to dump the log file and
 
  continue
 
   on to the install phase.  I know this can be done per-ebuild, but
 
  it'd be
 
   a useful global option.
 
  I, for one, would like to be able to control whether or not to run tests
  that take a huge amount of time to run. Some test suites are
  ridiculously comprehensive, and if we could have an option to disable
  only those, or even run a reduced test suite, that'd be pretty neat.
 
  --Ravi

 Who and what determines if a test is overly comprehensive and takes too
 long to run?

I think most everybody agrees that boost's tests are overly comprehensive. As 
for others like mysql,  a long test may be necessary to ensure everything is 
working properly.

-- 
2.6.22-gentoo-r8


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Bugzilla improvements

2007-09-27 Thread Thomas Anderson
Did your work have anything to do with the e-mails from bugzilla-daemon only 
containing HTTPS links? I noticed that over the previous few days.

On Wednesday 26 September 2007 22:04:40 Robin H. Johnson wrote:
 I went and processed a bunch of pending Bugzilla bugs, and thought folk
 might be interested in the changes.

 - Bug Reporting Guide is now linked from the front page as well as the
   Choose Product page (during bug creation). [Bug #188687]
 - The Log In link in the footer should take you back to the same page
   that you were on (please file a bug for bugzilla@ if it messes up).
   [Bug #188690]
 - SH, m68k, BSD in the 'Add Arches' Box. [Bug #178698, #178855]
 - Favicon fixups. [Bug #184565]
 - After changing a bug, the default behavior is now showing the updated
   bug, not jumping to the next bug in your last list. If you don't like
   this, you should change your own prefs.  [Bug #171988].
 - Do not reply note at the top of bugmail, and a related Reply-To
   header. [Bug #181172]
 - 'emerge info' = 'emerge --info' [Bug #173059]
 - During guided bug submit, users are asked to include the full package
   atom in the summary line. [Bug #165976]
 - Fix javascript bug with content-type selection during attachment of a
   file and using the drop-down box. [Bug #172513].
 - Do not display the banner for text-mode browsers. [Bug #78670]
 - Dupe box height in strict browsers fixed. [Bug #173158]
 - Use site-specific link color instead of browser-provided, for
   visibility when browser default is too light. [Bug #185760]
 - All internal links should stay on the HTTPS if you go there, and not
   take you off the HTTPS site. [No Bug#].



-- 
2.6.22-gentoo-r2
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] New eclass: cmake-utils.eclass

2007-09-10 Thread Thomas Anderson
On Sunday 09 September 2007 15:15:12 Wulf C. Krueger wrote:
 As I would like to introduce it to the official Portage Tree in
 preparation of things to come, we would welcome any comments, patches
 and, of course, your kind approval to commit it. :-)

Looks really nice. Just one question: What about colors? I know that some 
Cmake build systems color the compiles rather nicely(games-puzzle/ksudoku for 
example). It would be nice if the kde builds were colored that nicely, or is 
this an upstream issue?

/me knows absolutely nothing about cmake ;) yet
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] gentoo-commits list lives!

2007-09-07 Thread Thomas Anderson
On Friday 07 September 2007 20:25:07 Alec Warner wrote:
 On 9/7/07, Doug Goldstein [EMAIL PROTECTED] wrote:
  Mike Frysinger wrote:
   On Friday 07 September 2007, Robin H. Johnson wrote:
   On Fri, Sep 07, 2007 at 02:44:21PM -0400, Mike Frysinger wrote:
   X-VCS-Repository: gentoo-x86
   X-VCS-Files: udev-115-r2.ebuild
   X-VCS-Directories: sys-fs/udev
   X-VCS-Committer: zzam
   X-VCS-Committer-Name: Matthias Schwarzott,,,
  
   too bad we cant get herd/maintainer from metadata.xml :(
  
   Give me a service or something that can take a $CAT/$PN - that data,
   and I can include it in the headers for you.
  
   maybe someone knows of an easier way ...
  
   $ xsltproc gentoo-metadata-herds.xsl /path/to/metadata.xml
   base-system someherds
   $ xsltproc gentoo-metadata-maintainers.xsl /path/to/metadata.xml
   [EMAIL PROTECTED] [EMAIL PROTECTED]
   -mike
 
  Sure... be fancy with all your xsl and xml crap. LONG LIVE THE BRUTE
  FORCE PARSE WITH SED!

 People who parse xml with sed make me cry.

 grep = also bad.

What about people who parse xml with sgrep?

Parsing xml with sgrep is actually quite easy+useful.
-- 
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] /etc/ppp/(ip-up.d,ip-down.d} directories

2007-08-26 Thread Thomas Anderson
I would say, yes. This is a very important for some dialup users. I personally 
ditched the default way on my system because I couldn't do this. 

With regard to the concerns leveled at users defining their own scripts, it 
shouldn't cause too much trouble as long as the user knows a bit about what 
he is doing.

I do have one question though, how will this affect programs  like pppconfig? 
Programs such as these may not look at these scripts and break. Pretty much 
my one worry is about breaking compatibility with other programs in the tree.

--Thomas

P.S. Since this is a dialup type question, how many devs have done dev work 
over 56K dialup net connections?
On Sunday 26 August 2007 02:05:08 Alin Năstac wrote:
 A gentoo user requested in bug 190143 [1] to change the way pppd deals
 with interface up/down events. He requested to break current
 ip-up/ip-down functionality into different scripts contained in
 /etc/ppp/(ip-up.d,ip-down.d}.

 What do you think about? Is it worth it?

 Personally I think it is a good idea, but I have reserves when it comes
 to user defined {ip-up,ip-down}.local scripts. IMO the best way to solve
 this is to add this code to pkg_postinst():
 if [ -f ${ROOT}etc/ppp/ip-up.local ]; then
   mv ${ROOT}etc/ppp/ip-up.local ${ROOT}etc/ppp/ip-up.d/99-local
 fi

 [1] http://bugs.gentoo.org/show_bug.cgi?id=190143



-- 
2.6.22-gentoo-r2
--
[EMAIL PROTECTED] mailing list



Re: [gentoo-dev] Python 2.5 unmasked

2007-08-24 Thread Thomas Anderson
Thanks!
Is there any roadmap for stabilizing python-2.5(as in weeks,months, 
decades?) ;)
If anything goes into the GWN I think people running 'arch' would like to know 
when they will be affected.
On Thursday 23 August 2007 11:01:02 Tiziano Müller wrote:
 Hi everyone,

 Thanks to an increased number of people who helped with testing and fixing
 within the last two months, we were able to finally unmask python 2.5
 today.

 On behalf of the Gentoo Python Team,
 dev-zero



-- 
2.6.22-gentoo-r2
--
[EMAIL PROTECTED] mailing list