Re: [gentoo-dev] Adding --as-needed to LDFLAGS in profiles/default/linux/make.defaults
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
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 ?)
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 ?)
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
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
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
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
(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
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
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
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
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
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
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
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
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'
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
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
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
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
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
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
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 ))
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
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)
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
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)
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
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
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
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
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
[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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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]
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
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
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
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
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
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
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
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
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)
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
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
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
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
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?)
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)
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
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
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)
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
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
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
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
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
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
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!
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
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
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
