[gentoo-dev] Re: new partner in crime: Denis Dupeyron (calchan)
Hello everybody, SeJo wrote : I think we should all bow and welcome Denis Dupeyron. Thank you. Any relation with this other bending 'activity' you do with plasmaroo ? I urgently need to re-read the fine prints. He's a new addition to to the sci-electronics team. He'll be helping plasmaroo (grrr turn on the juice baby) with EDA for starters. Indeed, EDA is the thing I know best. But I also have an RDEPEND checker for ebuilds that may be of interest. It's in bash right now, so it's more a proof of concept than anything. I just need to fix one or two bugs that I have found recently, and then you'll be judge. SeJo aka Your Master Alright, alright, here's the stick. Beat me. Calchan. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites for dev-embedded/sdcc-cvs
The repository for SDCC has recently moved from CVS to Subversion. From now on, please use dev-embedded/sdcc-svn instead of dev-embedded/sdcc-cvs. dev-embedded/sdcc-cvs will be masked right now, and then removed in a month or so if nobody complains. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Packages that need maintainers
On 5/5/06, Daniel Goller [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The following packages require a new maintainer, some might just be absorbed into their herds w/o a direct maintainer leaving them to the teams maintaining those herds, others might face extinction w/o a direct maintainer. [...] ./media-video/kino [...] Does the media-video herd^H^H^H^Hgroup automatically inherit this one ? If not, and if nobody volunteers, I'm willing to salvage it. I have somewhere an ebuild for kino-0.8.1 that includes an --as-needed fix. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eutils.class fix for make_desktop_entry
On 6/5/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Go ahead and do it now. It really shouldn't break anything, as I can't think of a single thing using make_desktop _entry with a space in the executable name. What about games-board/gnubg-0.14.3 ? Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Last rites for dev-embedded/sdcc-cvs
Denis Dupeyron wrote: dev-embedded/sdcc-cvs will be masked right now, and then removed in a month or so if nobody complains. dev-embedded/sdcc-cvs is now removed. Denis. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Birth announcement : sci-electronics
Good news !The sci-electronics herd isn't one day old yet, but it is already diaper free (well, almost).In case you're interested to help, please drop us a message at [EMAIL PROTECTED]. And don't forget to bring your own soldering iron.Denis.
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On 7/7/06, Seemant Kulleen [EMAIL PROTECTED] wrote: I think the Council idea is great. However, I think the Council should be charged with a little bit of direction-setting and leadership as well. [...] 1. The council was (by design?) a reactive force, rather than a pro-active force. [...] This project needs some leadership, as the events of the past few months show fairly clearly. Agreed. We could decide we do not elect the council members based on their coding skills or any other type of technical skill. But instead have the nominees do some campaigning before the elections, and make direction-setting propositions for the coming year. Another thing that bothers me is the possible overlapping between council members, trustees and devrel. I wouldn't mind at all that any dev could only be one of these at most at the same time. I know that resigning from a position won't end the relationship between you and your ex-fellow devs from the group you've just quit, but at least functionally the link doesn't exist anymore. Plus, taking into account that we have a life outside of gentoo, and that these functions are the critical ones, having only one of these positions means a better chance to be efficient. Denis. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Dying on some CFLAGS instead of filtering them.
Dear devs, In bug #139412, I ask Paul de Vriese why he thinks python should die on --fast-math instead of just filtering it. Here's his answer : Denis, quite simple. -ffast-math is broken and short-sighted for a global flag. Filtering gives the shortsighted message that it works globally, while it is not suited for any package not specifically tested for it. As it breaks python, dieing makes people understand that it does not work on python. It is better than the alternative of not looking for it at all. This, for me, triggers 3 questions that are gentoo-dev@ material : 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? 2) If yes, are there any other flags that ebuilds should die on ? 3) Suppose that -ftracer, for example, is one of those, and knowing that enabling -fprofile-use enables -ftracer, shouldn't ebuilds also die on use of -fprofile-use ? It's only an example, this situation will exist for other pairs of flags. The hidden question behind these three is : shouldn't we have a something that enables us to safely handle this kind of situations ? Like some kind of system- and/or architecture-wide flag mask that could be overriden by the ebuild and/or the user (at his own risk) ? This could potentialy reduce the number of bugs that poor old bugzie has to cope with, and simplify ebuild writing and maintenance. If we already have such a thing, I'm sure you guys know where the cluebat is... But in any case, questions 1), 2) and 3) still need to be answered. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On 7/10/06, Ryan Hill [EMAIL PROTECTED] wrote: Ebuilds shouldn't die on anything according to the non-interactive portage philosophy. I don't know how official that philosophy is though. Correct me if I'm wrong, but this has nothing to do with being interactive or not. To me, an ebuild that dies (intentionally or due to a build error) isn't interactive at all. 1) Should all ebuilds that currently filter --fast-math die on its presence instead of filtering it ? No, that would be a major pain in the ass for anyone wanting to use -fast-math, which does have legitimate uses. If a package is known not to work with a certain flag, being able to emerge it won't change the fact that it doesn't run. Plus, if the solution is considered good for python, I don't understand why it wouldn't be good for any other package. Are you saying that Paul's proposition of having the python ebuild die on use of --fast-math isn't good ? If yes, why ? And what is your better idea ? 2) If yes, are there any other flags that ebuilds should die on ? There's a million, and they're constantly changing. For example, -frename-registers is generally safe on GCC 3.4, broken in 4.0, and enabled by default on 4.1. Which is exactly the reason why we could benefit of something that enables us to manage this in a clean and safe way. I'm not saying I have a candidate for that something, but I wanted to discuss if there was an interest in it. Let's take again the example of -ftracer which can be enabled by the -fprofile-use meta-flag. Imagine we have a mechanism somewhere (again, the reason I'm being vague is that my point isn't to discuss implementation just yet) that adds -fno-tracer to CFLAGS. In this case, you're covered wether -ftracer was added directly on indirectly by fprofile-use, which actually simplifies the number of flags that you need to blacklist. Thus ebuilds don't have to take care of it, bugs don't pour into bugzie, and Jakub can avoid overheating. Users playing with CFLAGS get to keep the pieces. Trying to dummy-proof the system doesn't help anyone but the dummies. ;) I'm one of those devs who care for our users. I think it's dangerous to try and categorize users in, for example, dummies and non-dummies, as you say. Who are we to judge this or that user is a dummy ? Plus, we all are the dummy of somebody else. Anyway, I was thinking more in terms of making the job of developers, bug wranglers, and poor old bugzilla easier, cleaner, safer. How many bugs do we have that are due to dangerous flags ? How much time and effort could we save if we didn't have those ? Also, I was thinking that if a good solution was found to deal with a dangerous flag in a certain package, maybe it was a good idea to extend this solution to other packages. And finally, if said solution becomes common, maybe it's a good idea to make it system-wide with a possibility to override the setting by the user or the ebuild. It seems we already have per-package CFLAGS, so part of this, at least, is already implemented. On 7/10/06, Richard Fish [EMAIL PROTECTED] wrote: My (user) opinion is that ebuilds should not die on CFLAGS, at least not until per-package CFLAGS are implemented. Why ? Stating your opinion without any justification isn't really constructive. And same as above : being able to emerge a package that won't run doesn't help you more. Now if someone is crazy enough to enable -ffast-math globally or specifically for python in that situation, well, die, spin the cpu fan backwards, melt the hard disk down and sell it for scrap, whatever you want! Same as above again, replace 'dummy' with 'crazy'. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On 7/9/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: Basically, if you're using daft CFLAGS you're on your own. Some ebuilds might filter them, some ebuilds might die and some ebuilds might let them through. Developers are under no obligation to add code to save users from their own stupidity, but they might do so if you ask nicely. Please re-read all the words in the previous messages. What I would like to discuss is not about helping users, but about making our job easier. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Dying on some CFLAGS instead of filtering them.
On 7/11/06, Ryan Hill [EMAIL PROTECTED] wrote: Their phrase, not mine. ;) I think the idea is you should be able to emerge -e world and walk away and not have anything interrupt the process thus requiring the user interact with the system. Well yes, but an ebuild that dies, whatever the reason, hasn't much to do with interactivity. If a package is known not to work with a certain flag, being able to emerge it won't change the fact that it doesn't run. If a package is known to not work with a certain flag it should be filtered so it does run. What will follow isn't only for you. You guys are focusing on the die/filter alternative. Maybe you haven't noticed but I have never stated that I'd prefer ebuilds to die or filter. What I wanted to discuss is can't we do something globally to avoid these bugs coming in, so that we can focus on something else. I don't care yet if it's filtering or dying. And never did I talk about educating the masses. Do you mean for ebuilds that knowingly break with -ftracer, or for everything? There are packages that expect to be built with certain flags; not -ftracer, but others. Fex, libao needs -ffast-math ;). Also, what about ebuilds that do use -fprofile, like gcc itself? I know toolchain.eclass strips all flags, I'm just using it as an example. I explained I was talking about a global system, with a possibility for ebuilds/users that wanted/needed it to opt out. It's much easier to unblock --fast-math for libao than going through idontknowhowmany bugs about the same number of packages that break with --fast-math, for example. If you mean just for packages that break with certain flags then absolutely. But such a mechanism would have to be maintained for every different GCC version, since -fprofile might not invoke -ftracer in every version, and indeed some versions might not even recognize -fno-tracer and bail with an error. Let's count together the number of GCC versions we should really care about. 3.4, 4.1, any others ? Mad props to the bug-wranglers, but I don't think it'll be a cakewalk to automate this in any sane way. Automate what ? Right, but how are people supposed to learn something is dangerous if all the sharp edges have been filed off? And how can you decide which flags are bad and good on a global level when for the most part compiler parameters are akin to black magic? Since when is being a learning tool one of the goals of Gentoo ? Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Stable Staleness (mostly toolchain)
On 7/30/06, Alec Warner [EMAIL PROTECTED] wrote: Another class of packages I wish to discuss (not remove quite yet, just talking ;) ) are older packages with stable markings. By Stable I mean debian stable, IE we stabled it in 2004 and no one has touched it since. Do these packages still work with a current system (linux 2.4/2.6, glibc-2.3/2.4, =gcc-3.4, etc... I have planned such checks/cleanups and more for sci-electronics (stabling, deleting very old versions when there is a newer stable version available, etc...). I'm going on devaway around august 5th, so that will probably be for when I come back late august / early september. I know that sci-electronics is a tiny part of portage, but I'll be doing my share, at least. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Resignation
On 7/31/06, Joshua Jackson [EMAIL PROTECTED] wrote: Thirdly, I know one of the issues with one of the leaders of the project, is the fact that they are not a ebuild developer. I'd like to have them take the second quiz simply to prove that they have the knowledge to be trusted to review the ebuilds. Course with the number that he's seen I'm sure he's helped take care of things that would make the rest of us go...how did they think that was ever a good idea. What if a well respected ebuild developper that supports the project volunteered to join it ? It could add some credibility to it and reduce the number of reasons that some people could shout about. I'm concerned that those against sunrise will claim that passing the end quizz doesn't give the sunrise leaders any more experience and credibility overnight. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sunrise contemplations
On 8/1/06, Jeroen Roovers [EMAIL PROTECTED] wrote: # emerge --submit-info * sys-apps/portage generates emerge --info output and uploads it relatively tamper-proof to tickets.g.o, and * returns a ticket to the user, a unique number that he or she can communicate to developers and active users through a URL like http://tickets.g.o/#ticket-number. * --submit-info includes information about the emerge commandline that was run last and what category/package/version emerge was building/installing at the time. Like you, I'm not sure this is necessary, but I like it. I like it even more when I think that the flags and other configuration options that are in make.conf at the time you 'emerge --info' are not necessarily the same as those you used when, maybe a long time ago, you emerged the dependencies of the package that breaks. Let's imagine we have : # emerge --submit-info package-that-breaks If that creates a compressed tarball of all (or selected relevant) data in /var/db/pkg concerning all packages that package-that-breaks depends on, I like it a lot. This will give more useful information than 'emerge --info'. And I'm not only thinking of forged 'emerge info', but also of those users and developers that play with flags because they like it or have to, and then forget to revert to safe flags. I'm sure there are many legitimate ways to make such mistakes. You end up having some parts of your system built with stupid flags, and you don't feel guilty about it because you don't even know (this happened to me already). So yes, I'd love to see something like this someday. And I'd love to help implementing it if such a decision was taken. But the question remains : it obviously looks useful, but do we need it ? Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise resumed again (was Resignation)
On 8/2/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: The alternative to elitism is mediocrity. Would you like Gentoo to be a mediocre distribution? The real world isn't binary. So there's a whole range of alternatives between elitism and mediocrity. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paid support
On 9/2/06, Donnie Berkholz [EMAIL PROTECTED] wrote: It might be worth putting together a list of folks interested in doing this on the Gentoo website, under a Third-party Paid Support section. We already have a Support link on the top of www.g.o, it could be on that page. I was thinking about something like this a couple of weeks ago. Similar to the adopt-a-dev project but for those of us who are students (or superhumans) and have enough time and want to make a buck or two with gentoo. We could list companies/people needing help either as a one-time action or on a regular basis (like a few hours a month), and starving and/or bored devs. The company I work for, for example, has gentoo servers only, and they use me as a consultant when they need it (my real job is not about computers). If they didn't have me they'd need somebody to help them, and I can hardly imagine it's the only company in the world in that case. Plus, that would probably make good PR for Gentoo. Denis. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-dev-announce] please sign your manifests
On Wed, Feb 13, 2013 at 8:31 AM, Aaron W. Swenson titanof...@gentoo.org wrote: This information, by the way, has been blogged about thousands of times. There is a reason people write documentation. Contrary to blog posts, documentation is thought out, reviewed, maintained and corrected when necessary. Blogs are written out of our collective ass in order to generate page hits or satisfy our ego, and forgotten right away. Ain't this handy. If you want people to handle security properly you have to tell them how to. In details. If not everybody will figure it out in his or her own way, all of them wrong. Get off your high horse and write documentation if you know how things work. That's more productive than this blabbering. Denis.
Re: [gentoo-dev] Google SoC @ Gentoo - Universal Select Tool
2009/5/4 Sérgio Almeida meph...@gmail.com: Please drop me a line here or at freenode if you have anything to add All I have to add is thanks a lot. I wished other SoC students would also introduce themselves and their project on their list. Denis.
Re: [gentoo-dev] Re: The fallacies of GLEP55
Joe ! How are you doing ? I've been meaning to call you but I've been busy as hell due to the move. Do you want to have a beer or lunch sometime ? Denis.
Re: [gentoo-dev] Re: The fallacies of GLEP55
Oops, that was supposed to be sent to him directly. Sorry about that. Denis. On Sat, May 16, 2009 at 2:11 PM, Denis Dupeyron calc...@gentoo.org wrote: Joe ! How are you doing ? I've been meaning to call you but I've been busy as hell due to the move. Do you want to have a beer or lunch sometime ? Denis.
Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)
On Sat, May 16, 2009 at 8:19 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Because the way Gentoo works, any objection to a proposal, valid or not, whether or not it's already been addressed, has to be answered before a proposal gets anywhere. Thus, every time people post nonsense about GLEP 55, every post has to be answered or the Council goes there are unanswered objection, so we'll postpone it. As usual you are extrapolating, but you're at least partly right. If the author had documented these objections and the answers in the glep then it would have made it possible to avoid most of what you call the nonsense. Anything buried on the lists, especially in such threads as those discussing this glep, can't even remotely be considered documented or addressed. The answers need to explain everything, even what seems obvious or stupid, in a way that all devs can understand. There is an attempt at doing this in the glep but it's long on asserting and short on explaining, and does not cover it all by far. As it is today the glep is a good draft but definitely not voting material, which is certainly one of the reasons why voting it is taking so long. Piotr, the author, is currently away and has been mostly inactive for more than a year now. I just talked to him on irc and reminded him that as per glep 1 the GLEP author is responsible for building consensus within the community and documenting dissenting opinions. Which he is clearly not doing, at least anymore. Whatever the reasons of his inactivity, the glep should be currently considered without a champion and its ownership should be transferred as stipulated in glep 1. Thus, I'm asking council to transfer the ownership of this glep, as well as glep 54, and restrain from voting on them until the dissenting opinions have been properly documented in each of them. Any new champion will be fine with me, but I'm proposing, if you agree, that you become the new champion as glep 1 doesn't require the champion to be a developer. I do not doubt that the practical issues due to you not being a developer will be worked around. Denis.
Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)
On Sat, May 16, 2009 at 3:18 PM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Except that at the last Council meeting, there were complaints that objections *had* been included and discussed in the GLEP, and claims that including such material made the GLEP less clear. As unfortunate as it is, council members have the right to forget about some of the details of some of our rules. And we have the right to remind them about them. This is another of those issues where whichever way it's done, some people complain. As long as you go by the rules those who complain about you doing so are wrong. I've been told you were not the kind who was afraid of being right. So, what do you think about my proposition ? Denis.
Re: [gentoo-dev] GLEP 55 updated
2009/5/17 Piotr Jaroszyński pe...@gentoo.org: I have just updated GLEP 55 [1], hopefully making it a bit clearer. Thanks a lot Piotr. Just FYI, my order of preference of solutions is: 1. EAPI-suffixed ebuilds (obviously) 2. EAPI in the filename with one-time extension change 3. Easily fetchable EAPI inside the ebuild and one-time extension change My preference goes to 3 with a .eb extension and EAPI on the first line. P.S. I know gentoo has other problems too, but it's the new and innovative stuff that makes working on Gentoo fun. We need all the problem solving people we can get. And since we're all volunteers there's no way we can force anybody to do anything. So, sure, there may be a need for prioritizing problems, but one problem solved is one less on the pile whatever it was. Denis.
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Mon, Jun 1, 2009 at 6:14 AM, Wernfried Haas a...@gentoo.org wrote: I'd like to counter-nominate you Aww... That must hurt. Denis.
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
2009/6/1 Dawid Węgliński c...@gentoo.org: I nominate: [...] Calchan Thanks Dawid, and also Ferris. I accept. You can find my manifesto at http://dev.gentoo.org/~calchan/manifesto09/manifesto.html Denis.
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Hi Doug, I just got to this thread, so sorry for entering the debate a bit late. I find your propositions very interesting. In my manifesto [1] I have proposed something significantly different which simply consists in spinning the long discussions off the council meetings using more focused groups (see the GLEP process and Experts paragraphs). I personally think our two ideas are complementary and not competing against each others. Denis. [1] http://dev.gentoo.org/~calchan/manifesto09/manifesto.html
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
On Thu, Jun 4, 2009 at 8:20 AM, Doug Goldstein car...@gentoo.org wrote: This is not a debate nor is this thread meant to be a launching point for people to promote their own campaign for being on the council and I chide you for taking it as such. I was just trying to contribute to the debate, no more. Since I had already written about this elsewhere I figured it was better to point readers there than just repeating it here. And for your info I'm not promoting any campaign. Where and when have you seen me doing this before ? I suggest you cool down a bit, and accept help and ideas from wherever they come. Denis.
Re: [gentoo-dev] Bug 244436
Hi Jean-Marc, On Tue, Jun 9, 2009 at 3:46 PM, Jean-Marc Beaunejm.bea...@gmail.com wrote: Sorry to be a pain but I just wonder if I filled this bug correctly because nothing happens: http://bugs.gentoo.org/show_bug.cgi?id=244436 I'm not putting any pressure in any way, I just want to know if I did it right. This already high traffic list is definitely not the right place for such a request, and neither is the bug you filed. Thank you though for filing this bug and offering your help. I have the feeling you haven't found all our documentation on how to contribute, so I will send you a list of links and some additional information. Denis.
Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
[...] This list is for technical discussions only. Also, public mailing-lists are not for discussing your personal issues. Denis.
Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
probably belongs in -project. Not even in -project, it simply wasn't public mailing-list material. For those who haven't understood yet, the -dev and -project mailing lists are not for keeping us informed of your random thought of the day or lamenting about why-oh-why-is-the-whole-world-so-unfair-to-me-when-I'm-being-so-nice-to-everybody-no-kidding. Keep tweeting it though. Denis.
Re: [gentoo-dev] 2009 Council Elections
Thanks for the reminder, Doug. Make sure to also check everybody's manifesto here: http://www.gentoo.org/proj/en/elections/council-200906-nominees.xml Denis.
Re: [gentoo-dev] 2009 Council Elections
On Fri, Jun 26, 2009 at 6:46 AM, Ben de Grootyng...@gentoo.org wrote: To appoint as proxy for a council meeting someone who has been booted from Gentoo is a clear lapse of judgement, and would in my eyes disqualify the involved council member from functioning in that position. As Petteri noted it's not obvious that GLEP39 disallows choosing a non-dev as proxy for a council meeting. I haven't talked to Tiziano, and I don't know what he had in mind when he chose ciaranm as his proxy, but I'd be ready to believe part of it was that he wanted to experiment. And experiments sometimes succeed, or sometimes they fail, but they often teach you something. I wouldn't be as fast as you to remove Tiziano from the list of people I'd vote for. Denis.
[gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
I'll have things to say about this but I'm still in the woods with dialup until monday. So either I can get close to a fatter pipe later today or tomorrow, or I'll do it on monday night from home. Denis.
Re: [gentoo-dev] Manifesto archive
2009/7/3 Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org: Yes, that is another thing I was planning to do. The only reason I haven't done it yet, is that older manifestos were stored as txt files and this year the candidates mostly opted for html/xml files. I'll probably just go ahead, ignore the looks and copy their manifestos to txt files. If any of the nominees would be kind enough to do it for us and send us the file, it would be greatly appreciated. I have made an html manifesto out of rst and a few others have copied it along with the makefile. So those of us who used rst have the source available, and I suggest you copy that instead of converting the html to text. You could also trim down my manifesto and turn it into an example and archive it with the makefile as a template for future use. Denis
Re: [gentoo-dev] Bug #250853
Hello Robson, On Mon, Jul 6, 2009 at 2:44 AM, Robson Roberto Souza Peixotorobsonpeix...@gmail.com wrote: http://bugs.gentoo.org/show_bug.cgi?id=250853 On bugzilla has the patch to solve the problem The people concerned by this already know about the bug and patch, there is no need to remind us here. They will get to it soon as they can. They're volunteers and do as much as possible in the free time they have. In addition, this mailing list isn't for specific issues such as this one, please use bugzilla instead. Thanks, Denis.
Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?
On Tue, Jul 7, 2009 at 7:45 AM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: Perhaps you should consider that it's your behaviour that's the issue here. It's both your behaviors, because they're extremely similar. Except that you seem to have more time available than slong to express your defensive personality on our various media. I'm going to have to ask the two of you to stop arguing in public, because very frankly we don't care. Plus it's completely off-topic and an abuse of our mailing-list system. Thanks, Denis.
Re: [gentoo-dev] Re: Re: A Little Council Reform Anyone?
On Tue, Jul 7, 2009 at 10:20 AM, Ciaran McCreeshciaran.mccre...@googlemail.com wrote: I contribute productively and usefully This should have gone in private but I want it to be public because you and others apparently do not get it. The fact that you're contributing or not does not give you or anybody else the right to behave improperly on our mailing lists, forums, or else. There is no amount of contribution that would compensate for even the slightest inadequate behavior. Please everybody, print that and pin it above your monitor. repeated pot-shots from the peanut gallery. Thanks for the good example. Please, you and everybody else, note that this above is considered abrasive by most of us. If you do this, not only do you pollute our mailing-lists, but you also attract more abrasive behavior from others. You only get what you deserve, so if you need to cry on somebody's shoulder then go see your mom. Do not express your hurt feelings on this list, we don't care. Not talking about making an ass of yourself for being so childish. Steve pops up every now and again and tries to disrupt things. You do the exact same in you own way. Please allow me to take that beam from your eye. Now, I suggest you do not reply to this mail in public as this would, again, be off-topic. Feel free to contact me in private though, I'll be happy to discuss that with you in case you need to. Denis.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Sat, Aug 1, 2009 at 7:10 AM, Sebastian Pippingwebmas...@hartwork.org wrote: I would love to see the GLEP on CPE names in metadata.xml discussed, http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg35155.html Any guidance on what I need to do to make it happen is very welcome. Please read GLEP 1 [1], and more specifically the GLEP work flow. Your GLEP needs to be submitted to and then accepted by the GLEP editors. Once it is accepted it will be assigned a number and you can discuss it on gento-...@gentoo.org (announce it on gentoo-dev-annou...@gentoo.org with reply-to set to gentoo-...@gentoo.org). Once that is done and a consensus has been reached you can submit your GLEP to the council for vote. In your particular case I'd like to know what are the plans of the other distributions. I would even think that they should be involved in the discussion process. And what happens when packages don't exactly overlap? Binary distros often use many sub-packages to work around their lack of something like our USE flags, and also to avoid forcing users to download a whole bunch of non-executable stuff when the binaries were patched. This thing isn't as easy as your (short) GLEP draft makes it look like. Denis. [1] http://www.gentoo.org/proj/en/glep/glep-0001.html
Re: [gentoo-dev] QA last rites for dev-tinyos/ncc; dev-tinyos/tos-make; dev-tinyos/tos-scripts; dev-tinyos/tos-uisp; dev-tinyos/tos-apps
On Sun, Aug 9, 2009 at 3:31 PM, Diego E. Pettenòflamee...@gmail.com wrote: # The rest are dependencies. The rest # of dev-tinyos might be added if it doesn't make sense # without these. Please last rite the whole thing if you feel like it. All my attempts at proxy-maintaining this have failed. Denis.
Re: [gentoo-dev] KDE Team Meeting - October 2009
2009/10/21 Maciej Mrozowski reave...@gmail.com: 1. Proposition to split desktop profile to: KDE, Gnome, (and maybe some others). How about making a desktop profile with everything common and being the parent of Gnome, KDE, XFCE, etc... sub-profiles with the specific stuff? Denis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-block/gparted: gparted-0.4.3.ebuild
On Sat, Nov 7, 2009 at 5:43 AM, Samuli Suominen ssuomi...@gentoo.org wrote: I'm seconds away from masking KDE 3.5.10, only fixing gentoo-x86 in a shape it's possible. So sorry everyone for not stopping on every single package and metadata.xml. Just getting this done. Quantity isn't a replacement for quality. Nobody's pressuring you, so you can take all the time you need to do things properly. You're a volunteer so you can do whatever you want, including a lousy job and not respecting rules. Just don't expect everybody to be happy with that. Denis.
Re: [gentoo-dev] Removing kde-base/arts from tree.
On Tue, Nov 10, 2009 at 3:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: I'm tempted to say otherwise it will be hardmasked with kde-base/arts by the end of this week, but that might be too intimidating for some. And completely unreasonable. Some of us have a life. Denis, wondering why the hurry.
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
On Sun, Oct 18, 2009 at 2:11 AM, Fabian Groffen grob...@gentoo.org wrote: This is a formal apology for springing that onto you. Thanks a lot. Not everybody can do such a thing as a public apology. I will nonetheless ask the council to vote on the following during next meeting: Ask Fabian to change his signature from: Gentoo on a different level To: Failure in a different level ;o) 2009/10/18 Tomáš Chvátal scarab...@gentoo.org: Why on earth portage simply does not detect the prefix enviroment is being run and then INTERNALY switch D-ED and other variables. If that means we can get away without touching ebuilds, apart from changing their EAPI variable, then that's absolutely what we have to do. I'd like things to be done the right way though (see below). On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller u...@gentoo.org wrote: However, there is need for additional discussion. From the council meeting log I could extract the following open questions: It would be preferable for the discussion to happen on this list before the meeting or we'll end up postponing again due to having more questions coming up at that time. 2. Should the Prefix team be allowed to do the necessary changes to ebuilds themselves, or should it be done by the respective maintainers? I think here it's obvious that anybody who is an ebuild dev and sees anything to fix (prefix or else) is encouraged to go ahead and do it, as we've always done. The recommendation is and will always be to talk to the current maintainers out of politeness and to be extra careful (i.e. usually letting the maintainers do it) in case of system/tricky/exotic package. We don't give full cvs access to the whole tree to all ebuild devs for nothing. 4. EAPI numbering: Would this simply be added as an additional feature to EAPI 3? Or should we have an intermediate EAPI slot, e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter case)? Here I'd add to the choices: why not release an intermediate EAPI with the prefix stuff and whatever that has already been done for EAPI3? The exact name of a potential intermediate EAPI is a non-problem. However I would prefer if it were a number like 2.1 or 2.5 or even 3, because although we currently treat the EAPI variable as a simple string we may change our mind later and find it handy someday to use operators on them such as =2.1. 5. Who is going to write the exact specification (PMS patch) for this EAPI feature? I thought I asked Fabian to work on that at the end of the meeting. In case I didn't then consider this as me officially asking him if he can take care of it. Fabian is this OK with you? Also I think it would be nice if somebody took care of a portage patch, since I hear it is rather simple. Fabian again? Or Zac? Any other volunteers? I would prefer to have all the pieces in places before the next meeting so that we can vote on the real thing and have prefix implemented the right way before the end of the year. 6. (Any question that I've missed?) Here are a few that I gathered from others (my comments are between parentheses): How are dynamically linked set*id programs going to work? How are scripts using #!shebangs going to work? You write an ebuild, and you DEPEND upon =foo-3, because the build process includes some foo code. The foo code is executed via scripts using #!/usr/bin/foo. Normally, this is fine. But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2 that's no good. So even though you've got the foo-3 dep met, it'll be met in /opt/Gentoo/blah, so your package will fail. How are ebuilds to be marked as supporting prefix or not? (Here I'm guessing that changing the EAPI variable will do) Why is there only a single permitted installation path? (I'm under the impression this is a limitation of the windows installer but not of prefix itself. So patching the installer would fix that) What exactly is expected from a prefix-compliant package manager to support full prefix installs, as opposed to just supporting installs to / with prefix-aware ebuilds? (The PMS patch should answer that) Denis.
[gentoo-dev] Re: mtime preservation
A quick note to tell you that I have tried to look for examples of breakage due to how mtime preservation is currently implemented in portage. Unfortunately I didn't find anything, maybe because I'm not knowledgeable enough or because I can't afford to spend any more time on this. If any of you can provide an example then please do so. In case nobody could show any sign of such breakage I would have to add to the list of two propositions to vote on: 3- Do nothing. We can always point to code that shows the implementation is suboptimal but we have to understand that some of us who are less proactive at fixing issues may want to procrastinate until breakage actually happens. Denis.
[gentoo-dev] Next council meeting on 7 Dec 2009 at 1900UTC
The next council meeting will be on 7 Dec 2009 at 1900UTC. If you want us to discuss things please let us know in reply to this email. What is already known is we'll talk about mtime preservation and prefix. You can find threads about those at: http://archives.gentoo.org/gentoo-dev/msg_a9e26414f2278275bdfa08baf839704f.xml http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml Denis.
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
Things seem to be progressing nicely on this front. We have answers to the questions people had and they look satisfactory to me. One thing that I think would be valuable is a document that explains the average dev how to make his/her ebuilds prefix compliant with links to more details when necessary. I understand that there's the trivial situations and the less trivial ones. In the latter case it would be nice to explain why the case isn't trivial and how to fix it. Using python as an example could be one way to do it. I'm thinking of something practical that could possibly be patched into devmanual. If such a document already exists then please just point us to it. On Fri, Nov 20, 2009 at 2:03 AM, Fabian Groffen grob...@gentoo.org wrote: I thought I asked Fabian to work on that at the end of the meeting. In case I didn't then consider this as me officially asking him if he can take care of it. Fabian is this OK with you? Yes, I agreed coming up with some patch. I admit I haven't yet even looked into it. Great, thanks. If you can have it ready some time before the meeting so that all devs can get a chance to review it before the council members vote on it that will be even better. If you need help don't hesitate to contact me. I'll try and look for the right people to help you depending on what you need. Technically, Portage trunk already contains the most important bits that allow us to continue since yesterday. The rest is waiting for a formal approval of the council, and then it will most probably be me and Zac fighting to get the prefix branch merged into trunk. Good. Next to that, it is part of the Prefix team's job to make sure that whatever is installed, does not reference the host system when this is not absolutely necessary. Could you give some examples of when it is absolutely necessary? Denis.
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
It looks like this question is still unanswered: On Thu, Nov 19, 2009 at 5:26 PM, Denis Dupeyron calc...@gentoo.org wrote: How are dynamically linked set*id programs going to work? Denis.
[gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On Sun, Dec 20, 2009 at 10:53 PM, Thomas Sachau to...@gentoo.org wrote: I will make it short, since i already requested it 3 times, did create a thread at gentoo-dev ML: agenda topic: Discussion and approval for following item: Adding real multilib features from current multilib-portage to currently hardmasked and testing portage-2.2* for wider testing, more eyes looking at it and hopefully more people helping improving it, so we can get a version, which most can accept for PMS and maybe next EAPI. Sorry, I forgot to send an email explaining what happened on the council alias as promised. The consensus was that the project wasn't mature enough to go ahead. Also more generally the council's job isn't discussing but deciding, approving, etc... Discussing is what should happen on mailing lists. Before you can bring that to the council we need to see an as-much-as-possible finalized solution with any of the following if applicable: portage branch with an implementation that people can try, documentation, PMS patch, devmanual patches, and a team. By team I mean: who is going to maintain this in the long run if necessary? A one man team is a dead team, it's only a matter of time. If the amd64 team is going to be the one doing this job, and this is just an example buy the way, then we need them to tell us they're OK with it. Now don't get me wrong. I love your project and the last thing I want is to shoot it down. Look at what happened with prefix. They wanted the council to approve it immediately or else... We didn't cede to pressure and worked with them to make it good enough for approval. Right now I don't hear anybody arguing about prefix going forward. And that's exactly what I want for your project, i.e. helping you making it better instead of it fading and failing in the (not so) long run. I will stop now because I'm at a bus stop near Mount Fuji and I need to go. I hope the other council members, especially the more technically competent ones than me, will get back to you on this and offer help and advice. As soon as I have a better internet connection I will contact you about this. Denis.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
2010/1/2 Pacho Ramos pa...@condmat1.ciencias.uniovi.es: [...] I failed to see if, finally, an approval from the council is needed for merging [multilib] to portage-2.2 or not The only approval that's required to merge anything to an official portage branch is Zac's (zmedico). He may have to follow some rules and wait for some vote from the council when for example EAPIs are concerned but whether to merge code or not is his decision and responsibility. That said I've never seen him refusing to merge anything that was worth it. if [multilib] will be discussed finally on this meeting. Technically we don't need to (I'll explain that in another email) but we may. I'm just starting to work on the agenda for the 18th and I don't have everything in place yet. Denis.
Re: [gentoo-dev] adding a modification timestamp to the installed pkgs database (vdb)
Brian,
On Sun, Oct 25, 2009 at 6:50 PM, Brian Harring ferri...@gmail.com wrote:
The proposal is pretty simple; if code modifies the vdb in any
fashion, it needs to update the mtime on a file named
'.modification_time' in the root of the vdb.
For example-
1) ${PACKAGE_MANAGER} fires ups, builds a pkg. it's now ready to
install it.
2) this step isn't strictly required, but is a zero cost safety
measure- prior to modifying the vdb, it updates the timestamp. The
reason for doing this is to protect against the manager blowing up in
some fashion and now updating the timestamp- there still is a window
if the manager breaks down during merging but it's far reduced.
3) manager does it's thing to the livefs, and to the vdb.
4) once finished, again, updates the timestamp.
This isn't an incredibly complex change. What it enables however is
package managers to get serious about optimizing access to the vdb.
For example for the 3 managers:
paludis:
installed-cache currently needs to be manually ran by the user;
specifically, the user is responsible for regenerating this cache if
they use a non paludis manager to modify the VDB. This can be
automated via checking the vdb timestamp against a stored copy of the
the vdb timestamp at the time of the cache generation.
portage:
portage maintains a set of denormalized caches of the vdb- it however
has to do validation of those caches on each access, meaning quite a
few stats. Same thing, can compare timestamp from current vdb to when
it was generated to identify if it is no longer authorative.
pkgcore:
pkgcore maintains a denormalized old style virtuals cache- same thing
w/ portage, it has to do validation (stat'ing) whenever it uses that
cache to ensure the data is accurate. Same thing, can compare
timestamp from current vdb to whenit was generated to identify if it
is no longer authorative.
The existing vdb caching could all be modified to use this timestamp.
One stat in the best (common) case, instead of having to either scan
the whole vdb each time or doing a subset of stats.
This change enables further caching/denormalization of the vdb data
while maintaining the old format- basically, it allows the manager to
build out a helluva lot faster access to the vdb while keeping on
disk compatibility in /var/db/pkg.
Now unfortunately since the vdb is not format versioned in any
fashion, to get this timestamp we have to do the following-
1) nudge everyone who has code poking into the vdb to update their
code to update the timestamp
2) sit on our hands for N months until such time we've deemed
everyone we care about has upgraded
3) push out a new release, and start pushing out versions of the
managers/vdb consumers that use this timestamp instead of just
updating it.
For anyone who has been around gentoo for a couple of years, this is a
pretty familiar pattern- eapi, profile changes, etc, all go through
this unfortunately.
That's the core of the proposal; there is a ticket open
( http://bugs.gentoo.org/290428 ) regarding this although there is
some debate from ciaran which I'll try to now summarize, along w/ the
counterarguments.
1) do a new vdb.
Counter: this mechanism provides a way to synchronize the new vdb
while maintaining the old during it's transition period, so this is
needed anyways. Further, pinning all of our optimization hopes on a
new vdb is daft- it's been discussed for 5+ years now and still
hasn't materialized (pkgcore has been able to have a new vdb for
several years, but without a synchronization mechanism it would
require locking users into the new format and locking out old
consumers of the vdb- an unfriendly choice to push on users, hence
never being implemented).
2) code that hasn't been updated to adjust the timestamp, but is still
in use after the transition period will break things.
Counter: nature of any modification of this sort, frankly the gains
outweight the costs of users being rediculously out of date. Not
saying it's perfect, but until someone comes up with a proposal that
versions every PMS component (meaning PMS has to start documenting
the VDB), it's what we have if we wish to move forward in
refactoring.
3) the correct approach is to require users to tell each manager that
changes have occured outside it's purview (run paludis
--regenerate-installed-cache after every time you invoke pmerge or
emerge).
Counter: that's rather unfriendly to users, and isn't what
pkgcore/portage do. Further, it's historically the opposite of the
norm- consider the ebuild cache (we do validation as we go there,
instead of expecting users to do a emerge --regen everytime they
modify an ebuild).
That's roughly the three points raised; there is some minor quibbling
that mtime cannot be trusted, but that's mostly a variation of #2.
This looks to me like a good idea. I see some of it at least has been
implemented in portage and I would suspect in
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
2010/1/12 Tomáš Chvátal scarab...@gentoo.org: Dont be joking, [...] Mmmh? Take a deep breath, a long walk, a large beer, or whatever works. Because you need it. Denis.
Re: [gentoo-dev] Support for multiple ABIs for amd64 (64bit,32bit) in multilib overlay
(I'm resending this email as the original apparently did not make it to the list, although Thomas probably received it) Hi Thomas, I'm replying to the original thread below to allow those who have missed it to have the full context. On Sun, Aug 16, 2009 at 5:37 AM, Thomas Sachau to...@gentoo.org wrote: Let me introduce a nice project, which was started by some users: Since the emul-linux-x86-* packages for 32bit libs for amd64 users are neither easy to maintain nor up-to-date, some users started to implement an eclass, which allows to build requested libs with additional 32bit support. Later i joined them and helped them improving it a bit, but it was and still is mainly their project, they do the main work keeping this overlay up-to-date. Also this overlay is a nice idea to drop emul-linux-x86-* packages, it either requires continual work or modification of many ebuilds in main tree to support this in long term. To avoid this, i took the original multilib portage patch from kanaka, adjusted it to the current portage code and added the ideas and code from the eclass version. The result is now a portage, which is able to build any ebuild with additional 32bit lib support. The current main regression are ebuilds and eclasses, which do not support this (e.g. perl modules and mysql). If anyone is interested: -for the eclass version, which is mainly maintained by users and is mainly intended to only replace the emul-linux-x86-* package: just add it via layman -a multilib (it should be pretty stable and mostly working). -for the portage version: It is also in the multilib overlay, but in a different branch called portage-multilib. To use this, you should read the instructions at [1] (doc/portage-multilib-instructions). This one should also mainly work, but there is probably a good amount of packages in the main tree, which may refuse to work with it. Bugreports: preferred way is #gentoo-multilib-overlay at irc.freenode.org, but we also have an alias, where you can contact us: multi...@g.o [1]: http://github.com/sjnewbury/multilib-overlay/tree/portage-multilib -- Thomas Sachau Gentoo Linux Developer I have already explained that I think it's a wonderful project and I definitely would like to see it in the tree sooner rather than later. There was a discussion on the council alias where everybody who participated seemed to like it too. However the consensus was that the project wasn't mature enough (I will let the other, more technical, council members comment on that). There are still open questions on this here thread, there is a request for low-level documentation and a high-level doc is also required (make it a request from me if you want), a preliminary PMS patch is needed, possibly a devmanual patch too, etc... I'm not saying we're asking you to do all this alone because this isn't how a collaborative project like Gentoo should work. We have resources and they are at everybody's disposition. We (I) will help you coordinate that effort if you need/want it. I have noted somewhere that you are concerned about having to do an EAPI bump and were trying to work around that. I understand your concerns and would tend to agree with you since in the past these things were not addressed smoothly and timely enough. This council showed however that we were ready to change plans and create EAPI bumps when needed [1]. If multilib is ready before or at the same time as prefix we can add multilib to EAPI3. If not, well, we will bump as needed by multilib or any worthy project/enhancement anyway. There is no point carving (the former) EAPI3 into stone and having it block everything else due to its implementation taking longer than anticipated. Also, there is no good reason for doing things the wrong way. If an EAPI bump is needed for multilib then let's just do it. I will personally see to putting this EAPI bump on the agenda when multilib is ready. And I'm convinced that at that time my fellow council members will simply vote yes. As you have noticed on the portage irc channel I discussed the maintenance of your branch with Zac. He has agreed to help you with that, and I understand that's your main concern at the moment. It appears that the portage repo is in the process of being converted to git [2] and this should make it a lot easier. I suggest you talk to Zac directly about this. Still on this subject, I will put the question of whether we should add this new multilib to the portage 2.2 branch or something more experimental on the agenda for the next meeting. I will also add multilib as a topic for the open floor discussion. Feel free to contact me in private if you have any question or need help with the above requests. I will do my best to assist you. Denis. [1] http://www.gentoo.org/proj/en/council/meeting-logs/20091207-summary.txt [2] https://bugs.gentoo.org/show_bug.cgi?id=196025#c34 and further
Re: [gentoo-dev] Monthly Gentoo Council Reminder for February
On Mon, Feb 1, 2010 at 4:30 PM, Mike Frysinger vap...@gentoo.org wrote: This is your monthly friendly reminder ! Same bat time (typically the 3rd Thursday at 1800 UTC / 2000 CET / 1400 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! Uh... no. The meeting is actually next Monday (January 8th) at 2000UTC / 2100CET / 1500 EST. We now adapt the date and time to suit our schedules and maximize everybody's chance to be available. Mike, could you please stop your cron job? It's now useless as I have to send the reminder email manually, which I do more or less two weeks in advance. Thanks, Denis.
Re: [gentoo-dev] GLEP58 - MetaManifest
You'll find below an email from solar to Robin about MetaManifest. I'm adding it to this thread (with solar's authorization) as it seems pertinent. Denis. On Thu, Jan 21, 2010 at 6:51 PM, Ned Ludd so...@gentoo.org wrote: Robin, I recall you wanted me to mail you what we talked about last nite in #gentoo-portage and I'll CC: the council so they have an idea what to maybe expect. So in our talking last night we discussed the fact that if the Manifest format has to change why not just get rid of it all together, and save some serious in tree space with the new MetaManifest's taking over all together. This would include MetaManifest's at the 2-level. You said the MetaManifest would need about 4 fields in them to describe the distfiles etc. Devs would still push normal Manifest's to the cvs tree so DIST can be obtained by the backend infra scripts. But those Manifest's could be dropped from the mirroring. if [ -e CVS ] then portage would need to use the existing Manifest's This method would hands down win my vote. As you know I'm not a fan of format changes in general as they can make the Gentoo experience suck, but if we are going to change formats. Lets do it right. The only downside I can see in this method is for people like drobbins who mirror our tree but overlay right on top of it then provide it back out. In such cases we should provide our backend scripts to the public so they can re MetaManifest. I'm probably forgetting all sorts of details from the chat. But hopefully this is enough to remind you, as well as giving the other council ppl an idea of what to maybe expect.
Re: [gentoo-dev] sudo vs su
On Sun, Feb 28, 2010 at 12:20 PM, William Hubbs willi...@gentoo.org wrote: I am starting this thread because I don't understand why people are using sudo and su together. They are completely separate utilities that do the same thing. AFAIK, it should be either sudo -i or su -, but not sudo su - which I have seen quite often. sudo su - is redundant because su - does the same thing as sudo -i. sudo -s, afaik, gives you a root shell but does not clear out the environment first. Am I completely missing something? Some systems are configured with a random root password. After a while you get tired of doing 'sudo command' all the time and would like to become root but you can't because you don't know the root password. One way around that is 'sudo su -' which allows to become root using your user password. Denis.
Re: [gentoo-dev] Qt3 mask breaks significant science packages
On Fri, Mar 12, 2010 at 6:18 AM, Robert Bradbury robert.bradb...@gmail.com wrote: It would appear that the pending (0321) mask of Qt3 will break sci-misc/qcad, sci-chemistry/xdrawchem and x11-misc/glunarclock. I'm not concerned but I feel sympathy for those who use these packages and many others. The decision from the qt project to remove qt3 and all its dependencies from the tree is suboptimal to say the least. A library project should be at the service of those using the library, not dictating to those using it. That said they were perfectly entitled to make the decision of not wanting to maintain qt3 any longer. The only advice I can give is that all disgruntled users and developers create a qt3 project and adopt/unmask/re-commit the qt3 libraries for maintainers of packages who need it. I doubt this will happen as this could have been done a long time ago, but it's never too late. Denis.
Re: [gentoo-dev] Is Gentoo a Phoenix?
On Sat, Apr 3, 2010 at 5:33 AM, Richard Freeman ri...@gentoo.org wrote: I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. All ideas regarding improving recruitment are welcome, thanks. However if, during your review, you were not given the impression that your maturity and other social skills were being assessed then you were being blissfully naive. :o) I use tricks like pretending I don't understand that crystal-clear thing you're explaining to gauge your patience and politeness, I drift off to real-life topics to find out who the recruit really is, and lots of others like background searches (also outside of gentoo) and talks with the mentor. On the other hand, in your particular case, I clearly remember the assessment was easy and thus I didn't insist too much. Which is what probably made it more difficult for you to notice. Denis.
Re: [gentoo-dev] Is Gentoo a Phoenix?
On Mon, Apr 5, 2010 at 9:33 AM, Richard Freeman ri...@gentoo.org wrote: What I was getting at is trying to identify what aspects of the whole recruitment process added the most value and which added the least, and adjusting accordingly. I think that assessing attitude and maturity, and providing the tools and education needed are the most critical aspects of recruitment. Agreed. Although the education part should come from the mentor. Recruiters are only supposed to fill in the gaps because there's only so much they can do. Nowadays most mentors only really care about making sure their mentee gets the quiz answers right. That's a big mistake. I've been mentoring somebody to help me with sci-electronics for months now (hi Rafael!), and the quizzes are less than 5% of what we spend time on. So what is it then? English and how to communicate was the big thing at first but he's doing much better now, then working on a lot of ebuilds in and outside of bugzilla, but also how to efficiently deal with people, why things happen in a volunteer project and most importantly why they don't, how to not get discouraged by many little annoying things, etc... That's the kind of things a mentor and thus every gentoo developer should invest time in because it pays back big time. I've been toying with a project about training mentors but can't find the time to set it up. The idea was to have interactive sessions on irc with a few interested devs. That's why I'm all for changing the approach to quizzes - from my experience it wasn't the quizzes themselves that really added the most value for me. The interaction that they triggered and getting me to consider some of the more critical issues that come up in ebuild maintenance added far more value than getting every detail of the answers 100% correct. I do make sure that answers are 100% correct since I consider that part of the necessary paperwork to be recruited. However during the review I use the quizzes mostly as a way to engage conversation on a lot of topics, not only technical. That's the reason a review with me lasts anywhere from 5 to 12 hours. So in a sense what you're thinking of is already happening. Denis.
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sun, Apr 4, 2010 at 3:16 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: I see no reason whatsoever to keep it open. How about this one: preventing users from filing dupes. If we start doing that, we'll end up with tons of extra bugs on our hands. What's the big deal? You know you'll be adding/bumping the package at some point. Just close the bug when you do so. It's certainly less work than marking it RESOLVED FIXED once and then DUPLICATE many times after that. The point of bugzilla is tracking bugs, not a tool to arbitrate a pissing contest about who has the least bugs open. If you can't/don't want to fix a bug that's OK, but it's not a good enough reason to pretend it never existed. Denis.
Re: [gentoo-dev] Should we disable RESOLVED LATER from bugzilla?
On Sat, Apr 3, 2010 at 9:25 AM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: I disagree. Resolved LATER is useful to some maintainers that want to fix that bug, but don't have time or don't find the issue to be a priority at the moment. By marking it LATER they're acknowledging the bug exists and needs to be taken care of. Reassigning the bug to yourself (or the herd) if necessary, accepting it, and then explaining what/who/why/etc in a comment is the way to go in that case. No system, however good it is, will replace proper communication. Denis.
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 5, 2010 at 11:57 AM, Jon Portnoy av...@eris.oppresses.us wrote: Which is all well and good -- the you wrote some ebuilds so here's your commit privs and @gentoo.org approach to recruitment worked great when Gentoo had a few dozen developers. Today QA is a bit more important, and development is often rather more complex than new version, bump the ebuild -- it's important that new developers have a firm understanding of ebuild complexities. That's a very important point. On one side there are developers and would-be developers who want an easier way to recruit people. Most ideas revolve around lowering the technical/social barriers. On the other side there's QA and a bunch of other developers who want fewer people screwing up the tree. Those are proponents of being stricter during the recruiting process (i.e. in the end recruiting fewer people) and firing more devs. None of them though help the poor guys in the middle. Those are the recruiters who could swing completely one way or the other for simplicity, or be more subtle and try and make the best out of the situation and resources. When you're all done barking, and in case you really consider helping here are two things you can do: - join the recruiters - actually *mentor* people to become developers. And by that I don't mean passing them your quiz answers, but really training them and preparing them to become good and well behaved developers. When people ask me how to go about that my usual answer is do as you were teaching your son/little brother how to fly fish (or replace fly fishing with what you do best). Start from the start, progress from there, don't overlook any aspect of the art (there's more to being a dev than writing ebuilds), and be ready to spend hours explaining and re-explaining. If your recruit doesn't get it then it can only be your fault, so try harder. Before you replace/change a system you should first try and make it work. II don't even like resurfacing to post to -dev. Just here to offer some insight on why we originally kept the quiz system. Hi Jon, long time no see. Thanks for doing that. Denis.
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On Mon, Apr 5, 2010 at 12:51 PM, Nathan Zachary nathanzach...@gentoo.org wrote: [...] but it would be much more enlightening to me to work on creating ebuilds while working one-on-one with a mentor. The whole purpose of the training period between the ebuild quiz and the end quiz (see [1]) is exactly this. If your mentor isn't doing that with you then look for another one who will mentor your properly. Don't blame the system when it's not used. Denis. [1] http://www.gentoo.org/proj/en/devrel/recruiters/mentor.xml
Re: [gentoo-dev] Re: [Gentoo Phoenix] recruitment process
On Tue, Apr 6, 2010 at 7:28 AM, Duncan 1i5t5.dun...@cox.net wrote: But while I don't do IRC, from various hints I've seen here, that hasn't necessarily been the case there. I'm not making a judgement of whether that's good or bad and am only going on various asides I've seen here because as I said, I don't do IRC, but that's the impression I've gotten. There's something to be said about not trusting hearsay, and also about not talking about something you haven't witnessed yourself. In other words it looks like you might have wasted an opportunity to shut up. Denis.
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 8:23 AM, Ben de Groot yng...@gentoo.org wrote: 1. reconsider metadata changepolicies proposal == [...] Can council please decide to honor the wish from developers to implement this? The council will be glad to vote on a GLEP when ready. From GLEP 1, GLEPs are the primary mechanisms for proposing significant new features, for collecting community input on an issue, and for documenting the design decisions. So use them. Also, you might want to check the log and summary of the last meeting to find out why the council may end up voting no to such a GLEP. 2. website redesign === [...] Can council assure that a team will be assembled that can effectively tackle this issue? You want the council to aim their collective gun at volunteer developers and force them to assemble in a team and work on something they might not want to work on? In other words, if you want it then work on it and make it happen. This is and has always been the Gentoo way. 3. manpower and recruitment issues == Another recurring theme is the lack of manpower in certain areas, the recruitment bottleneck and the quizzes. There are some initiatives but more decisive leadership is needed. Can council decide to actively pursue solutions for these structural problems? The only way to solve this is to address these issues where they are. That means joining the recruiters team and helping them with that. Another thing you might want to do is properly mentor recruits. Because one reason recruiting takes so long, and thus why there is a backlog, is (to put is simply) that mentors suck at mentoring. 4. devrel ineffectiveness = In case you haven't noticed there was a recent change of devrel lead. This means it is urgent to wait for the results of the change. Because you never know, it might just be that the change of lead was intended to solve such things at a perceived devrel ineffectiveness. 5. centralize developer documentation = This is an interesting idea which I believe I have seen discussed on irc at some point. Feel free to work on a GLEP to address that. Before we go any further, let me make the following PA announcement: 1 - If you want to improve a project or subproject the best (and often only) thing to do is to join it. 2 - The council isn't a super-nanny metaproject with enough magical powers to solve each and every of your oh-so-annoying problems. We do have magic wands but you don't want to see them. Denis.
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 11:14 AM, Ben de Groot yng...@gentoo.org wrote: So all I'm asking is to do your job and make decisions on issues that affect all of Gentoo. The issues I brought up are wider than a single individual project. And almost 100% of the time this needs to run through a GLEP, which is the case here. Then the council will do all the things you've pasted from GLEP 39. Denis.
Re: [gentoo-dev] Council meeting 19 April 2010
On Wed, Apr 7, 2010 at 4:30 PM, Richard Freeman ri...@gentoo.org wrote: Sure, it is the best way to make big changes Why then use anything else than the best tool when you can use the best tool? I didn't say that he should work on a GLEP though, but that he should feel free to do so, which is different. That meant that if he thought there was a point to it, was willing to do it, etc... Just a note about this. The council could for example make the decision to centralize all the documentation in a wiki, force the doc team to use tools they haven't chosen or even take that responsibility out of their hands. Basically step on their toes. Nice way to show respect for all the hard work they've done for years. Or this could be discussed on the relevant mailing-list(s) by everybody who feels concerned, input from the whole community (including the doc team) could be gathered, council members could chime in (I usually do), dissenting opinions could be documented, a consensus could be reached and then design decisions could be documented. See GLEP 1 for more information on that work flow. Gentoo has been driven by consensus since Daniel left, for better or for worse. You might not like this way to work, but that's OK. I didn't say I thought it was optimal either. All I know is I'm going by the book, but it allows me to rewrite some pages when I don't like them. The good news is that during the last meeting the council has decided to initiate an overhaul of GLEP 39. I'm still gathering material from various sources to start the discussions open to all users and developers. At that point you'll have the opportunity to suggest anything you think may improve the way the council works. However, the council can still show leadership in affirming their agreement on issues even if it isn't a formal affair. We don't need a meeting for that. We can show leadership on the mailing-lists everyday. What do you think I'm doing right now for example? And by the way I don't believe that issuing a statement along the lines of Yep, we agree shows any leadership at all. Additionally, leadership is not about doing your job. You may want to peruse the council meeting logs and summaries for examples of leadership, and vote for real leaders next time if you think we suck. I'm sure every other town government in the Western World has taken a vote in support of their troops or something like that without going through the official lawmaking process and all that - it is just a gesture. We've been down that road many times before, but let me say it again: Gentoo is not a government, so any comparison to one is pointless. I don't have the time to create such a website although I would agree that it is sorely needed. Hence, I will try to be careful in throwing around criticism - it is much easier to bring problems to the table than solutions... Wise words, although constructive criticism is always welcome. In order to be really constructive however, criticism needs among other things to take into account goals, resources, history and rules. Denis.
Re: [gentoo-dev] Who is willing to be lead?
Ben, Petteri was proposing an idea. He is being creative and is trying to help. The only way of knowing if his idea is good is to discuss it and later try it if people are interested. You, on the other hand, have lately been increasingly critical (which is good) but not constructively. You obviously have a lot of energy but at no point have you offered your contribution. You haven't offered to help the teams you've been criticizing and you haven't proposed any real idea (website redesign, recruiters). Also you're criticizing without knowing what is happening when the information is publicly available (you're asking for a discussion on the metadata idea and it was a topic last month, the devrel issue is being tackled and it started before your rant). On Sat, Apr 10, 2010 at 8:38 AM, Ben de Groot yng...@gentoo.org wrote: I am willing to follow real leaders Willing to follow? Wow, that's ballsy. Now I understand why you needed to tell the world about it. who inspire and lead by example, There are lots of good role models to follow in Gentoo. All those who work their ass off trying to make this distribution better, and use the mailing lists as a tool to share ideas but not for immature political rantings. You've just shown a striking lack of such leadership. No cheers this time, And you've shown a striking lack of respect for somebody who's been so dedicated to Gentoo for more time than you've been a developer, and without whom you wouldn't even be a developer as he was your recruiter. This is so wrong. Credibility is among these things which take a long and hard work to build up and can completely blow up at any time. Don't waste yours. Denis.
Re: [gentoo-dev] Who is willing to be lead?
On Sat, Apr 10, 2010 at 3:43 PM, Petteri Räty betelge...@gentoo.org wrote: On 04/11/2010 12:37 AM, Ben de Groot wrote: How about: You have lately been increasingly critical but not constructively at no point have you offered your contribution You haven't offered to help you haven't proposed any real idea As I read it he was referring to specific things like recruiters not your contributions as a whole. Exactly. use the mailing lists for immature political rantings As for this I said he could have refrained from mud slinging, didn't I? No mud slinging there but a fact. You can either ignore this kind of behavior and let them pollute our mailing lists, or you can point at them and say they won't be tolerated. I chose the latter. Denis.
Re: [gentoo-dev] Who is willing to be lead?
On Sat, Apr 10, 2010 at 4:10 PM, Petteri Räty betelge...@gentoo.org wrote: I mean things like immature political rantings are not likely to evoke the wanted response and it didn't happen here either. I know it hurts the eyes a bit, but calling problems by their name is part of fixing them. Denis.
[gentoo-dev] Re: [gentoo-council] Policy regarding the inactive members
On Sun, Apr 11, 2010 at 7:16 AM, Markos Chandras hwoar...@gentoo.org wrote: Hello folks, Hi Markos. A small detail first. You shouldn't cross post as it makes things confusing and often results in threads splitting. I have no problem with that because my email client merges threads but it's not the case for everybody. Looking through the Council project page, the policy regarding the inactive council members doesn't look optimal to me If you look at the summary of the last council meeting you will see that I was tasked to start discussions on rewriting GLEP 39. I have gathered input from various sources and will start posting the discussion topics real soon now. One of them is about voting by email which impacts the slacker rule. Your email will be particularly useful for the discussion of that topic. 1) He is inactive in critical discussions ( such as the whole Phoenix discussion ) for a certain period of time This is an interesting concept but finding a metric to gauge activity based on mailing list discussion is very difficult for two reasons. You use the example of the Phoenix discussion as one where council members should have posted to show their activity. However, although you consider me active you may have noted that I haven't publicly participated to it. This doesn't mean I don't care or don't have an opinion on it. But, and this is the other reason, much of the work I do is done in private. Not that I want to hide anything but I read threads and based on what developers and users say I ask questions, advise, (re-)motivate, or connect people, etc... And I do that in private because it doesn't make much sense to have those conversations on mailing lists, and also because you guys already see enough of me there. 2) Fails to accomplish his role by supervising the Gentoo projects. Remember we have plenty of Gentoo projects nearly dead and there is no way for us to participate since contacting the project leaders is a no-go. Indirect question: Is the council aware of the status of all projects? Shouldn't it be since he is responsible for them? Another hard one to find a metric for. Beyond that, when I wrote my manifesto for last year's elections I talked with other developers about the possibility for the council to audit projects on a volunteer basis. By audit I meant and explained that the council would closely look at a project at their request and offer advice on short and long term operation. This wasn't well received at all, to the point that I didn't even bother adding it to my manifesto. It seems that project leads like to consider their project as their own little corner of Gentoo, and don't like too much to be interfered with. I'm personally OK with that. One of the reasons is that we rely on volunteer manpower and you can't force a volunteer to do anything (s)he doesn't want or like or (s)he'll leave. You have to be very careful when interfering with their work and find the right balance which will change from one situation to the other. One example I remember is when last year the kde project was considering going forward without a lead. It isn't technically a top-level project so it isn't required to have a lead. I thought that in the case of such a large project it was a bad idea to not have one though. I wanted to force an election but decided I would wait for the right opportunity to make it happen as smoothly as possible. Jorge will probably confirm that there was no arm wrestling involved. Making such things happen without hurting anybody and stepping on anybody's toes requires a lot of thinking and planning. From the opinion of a lot of devs it's about as far as one should go. By the way this is probably the kind of leadership Ben was referring to in his recent thread, although I didn't mention it there as I don't like bragging about these things. I feel sorry to admit that the current council failed to become a good leader for Gentoo and his inactivity demotivates both users and developers I partly agree with you. I considered resigning last year when I saw the disaster from the inside. Ferris convinced me that the right thing to do was to stay on and do my best to keep things working and change them when necessary. Which I'm still trying to do, but right now I'm not sure I'll run next time. Denis.
Re: [gentoo-dev] RFC: virtual/icon-theme
On Tue, Apr 13, 2010 at 12:47 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: I think that the packages that currently depend on one icon theme, could instead just depend on that virtual. For example, xfce works fine without the xfce theme, provided some other theme (like gnome or tango) is there. Is it a requirement that more than one package should depend on it until we can extract a virtual? I think it would simplify managing the dependencies anyway. This is very similar to when you want to add a global USE flag. In that case we usually require 5 packages and a general non-specific purpose. It can easily be translated to the present situation. More practically I would say: use your brain. If you think it makes sense then go for it. Denis.
Re: [gentoo-dev] Re: Gentoo Council 2010/2011 - Nominations are now open
On Sat, Jun 5, 2010 at 8:36 PM, Ryan Hill dirtye...@gentoo.org wrote: I'd like to nominate betelgeuse, calchan, and ssuominen (no way you're getting out of here that easy). Thanks a lot for your confidence but I'll pass. Denis.
Re: [gentoo-dev] Tone in Gentoo
On Sat, Jun 19, 2010 at 8:37 AM, Sebastian Pipping sp...@gentoo.org wrote: I was more or less told to fuck off if I don't like the tone. Please watch your language, this is a public mailing-list. Denis.
Re: [gentoo-dev] gentoo-x86 commit in sys-cluster/csync2: ChangeLog csync2-1.34.ebuild
On 9/20/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: On Thursday 20 September 2007 19:54:16 Donnie Berkholz wrote: econf has default econf failed die message. The following would be sufficient: econf \ --localstatedir=/var \ --sysconfdir=/etc/csync2 Is that so ... when did that appear? Does it happen for all of the package managers? Which functions do this? Where is it documented? The currect PMS draft documents it (for econf only). All three package managers conform to it. As you seem to know, PMS is still a draft and as such can't be considered a valid reference document yet. The econf function is indeed the only one that is officially documented as aborting automatically via die(). You can find this in our Gentoo Development Guide available at devmanual.gentoo.org. In any case it is considered good practice to always add '|| die(message)' after all helper functions. The reason is you can't (or shouldn't) rely on any of them dying properly now or in the future. Plus adding a specific message helps debugging. And about the existence of other package managers, yes, I've heard that rumor too. I've even heard that they may work, but I can't confirm. Denis. ���^����(� ��X��X�
[gentoo-dev] Last rites: net-print/hpijs
# Denis Dupeyron [EMAIL PROTECTED] (23 Sep 2007) # Masked for removal in 30 days as per bug #176962. net-print/hpijs Upstream decided to kill hpijs and replace it with hplip quite a good while ago. The replacement is much better and much more usable. So, net-print/hpijs has been masked for removal in 30 days. Please use hplip instead, or have your lawyer talk to my lawyer about why you would still need hpijs. Denis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New developer : Timo Gurr (tgurr)
It's my pleasure to introduce Timo Gurr (tgurr) who will join us as a new developer. He will work primarily on KDE and printing. Timo lives in Neckarsulm, Germany, and works as an IT technician in a local city administration near his home. He finds his job very interesting and loves it, and even runs some Gentoo machines there. His interests are very wide-ranging and he likes to play a good game from time to time. This makes him believe he is a pretty normal guy. Well, let me tell you something, Timo. You've just entered Gentoo-land, so please leave all normality at the gate. Thanks for your understanding. Let's all give him a very warm welcome. Denis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New developer : Mike Pagano (mpagano)
It's my pleasure to introduce Mike Pagano (mpagano) who has been wrangling kernel bugs for some time already, and will now do so as a full Gentoo developer. Mike lives in his native New Jersey with his wife and a large cat. He currently works for a Pharmacy Benefits Management company where he helps set the company's long term 3-5 years strategy. He is also an amateur cyclist who logs a bit over 4000 miles a year, with a racing career that has slowly given away to age. Yes people, Mike is older than Uncle Seemant, and even older than me. So kids, please, don't go and disturb him while he's having a nap or reading a book which are two activities that he enjoys. Let's all give him a warm welcome. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in games-kids/gcompris: ChangeLog gcompris-8.4.ebuild
On 10/8/07, Donnie Berkholz [EMAIL PROTECTED] wrote: cp /usr/share/gettext/config.rpath . Shouldn't this respect ROOT != / ? I can see how that would be a bit of an unusual use case for games, though. While we're on that topic : [EMAIL PROTECTED] /tmp/gcompris-8.4 $ ./configure --help [...] --disable-rpath do not hardcode runtime library paths I don't recall seeing this in previous versions. This whole thing is certainly beyond my understanding, but could this option enable us to avoid that ugly copy of config.rpath in src_unpack() ? Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
On 10/10/07, Zac Medico [EMAIL PROTECTED] wrote: I think it's OK to start using package.use now considering that package.use has been supported since portage-2.1.2 and that's been stable since February. There are already a couple of packages using it in the tree now. Is it a good idea for those ebuilds that require new features to have a = dependency on a specific version of portage ? Or not ? Can this help when switching EAPIs ? Or plug the gap while the decision to switch to EAPI=1 is being taken ? Does /me need more coffee or a good clue-batting session ? Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Getting rid of lurking no* USE flags - profile-based package.use
On 10/10/07, Zac Medico [EMAIL PROTECTED] wrote: Eventually I'd like to add an option that behaves similar to --resume but also recalculates dependencies. Why not make that the default ? That would be safer IMO. Plus, once we have this, it looks to me that nobody has to wait for EAPI=1 in order to use whatever portage feature that's needed by an ebuild. So we can all stop complaining about not having EAPI=1 in the form we wanted or at all, and get back to writing ebuilds. Denis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New developer : Dawid Węgliński (cla)
It's with an unusual delay [1] but with the usual pleasure that I'm re-introducing Dawid Węgliński who goes among us under the much-easier-to-type nickname of cla. If it's a re-introduction it's not because the second time is always better, but because he has already been active as staff for some time in the gentoo-artwork subproject of -desktop. He will now be a full developer and work with the net-irc and x86 arch teams. Dawid is from Kłodzko, Poland, and is a part-time forestry student and worker. I suppose that means he is a tree-tamer. Dawid, you want to be careful with those trees, OK ? I haven't been out of that padded room in a long time, but I've heard these things bite and their claws are nasty. And also that grass (no Taco, not that kind) and bushes (no vapier, not that kind) are their allies. I would even watch those flowers very carefully if I were you. Please everybody give a warm welcome to Dawid. Eh ? We already did last week ? Don't mind me then... Denis. [1] Great story, kids. I tripped on a wire last week and got stuck in a space-time trap as a result. I'd still be in that state if my wife hadn't needed to recharge her epilator and noticed the unplugged wire. Who said we didn't need women ?
[gentoo-dev] New staff : Marion Agé (titefleur)
It's my unusual pleasure to introduce Marion Agé who will go among us under the nickname of titefleur, which can be literally translated into lil' flower. Aint that charming ? Marion will be the new translator follow-up for French. Her experience is mainly in web development. her knowledge Marion lives in Lille, France. ���^����(� ��X��X�
[gentoo-dev] New staff : Marion Agé (titefleur)
It's my unusual pleasure to introduce Marion Agé who will go among us under the nickname of titefleur, which can be literally translated into lil' flower. Aint that charming ? Marion will be the new translator follow-up for French. Her experience is mainly in web development, with knowledge of PHP, MySQL, xhtml, css, xml, javascript, ajax, flash... Oh, and there's bash and python too. She also participates to projects which promote open source and free software. Marion lives in Lille, France. She likes playing guitar and piano, photography, acrobatic roller-skating. She loves riding horses, and her parents have horses at home. Please everybody, give Marion a very warm welcome. Denis.
[gentoo-dev] New staff : Elias Pipping (pipping)
It's my pleasure to introduce Elias Piping (pipping) who is joining us as staff. He will do general development and bug solving for the Gentoo/alt project. Elias is familiar with Tcl, Ruby, Python, Perl, Java, sed, awk and bash. He admits having above average knowledge of regular expressions, and I suspect that should be read way above average. He has previously contributed to the MacPorts project. Elias studies mathematics in Berlin where he has always lived as he doesn't like to travel. He doesn't have a TV and reads only programming-related books. He enjoys english and frequently goes to the movies. Please everybody, give a very warm welcome to Elias. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild
On Nov 9, 2007 11:28 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: Looks like it's a silly hack [...] Which is rather perverse Whoever it was, whatever it was, nobody deserves to have his/her work to be qualified this way. All of us (including you) would benefit of a more neutral language. Although not totally offensive, you're walking a fine line here. Please make sure this little quirk of yours doesn't bite us (that includes you again) anymore. Thanks in advance. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/cups: ChangeLog cups-1.3.4-r1.ebuild cups-1.3.4.ebuild
On Nov 10, 2007 2:58 PM, Daniel Pielmeier [EMAIL PROTECTED] wrote: Gentoo is a worldwide project, so i guess many of the contributors are not native speakers. See the gentoo-devs all over the world [1] as an example. Okay english is the common language here, but is it that difficult to articulate in a way that everybody can understand and not to use words which could easily be misunderstood. Lucky you are that your native language is one of the world's most widely spoken languages. Imagine to express yourself in a language you are not familiar with! I hope everybody can understand this, as i am not a _native speaker_ too! [1] http://www.gentoo.org/proj/en/devrel/roll-call/devmap.xml? Please do not argue with him. He does this kind of baiting once in a while in search of some action. My previous message was only a seasonal reminder of the fact that we know that he knows what his problem is, although he is naive enough to think we are naive enough to play with him. Denis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Last rites: net-print/hpijs
On Sep 23, 2007 12:48 PM, Denis Dupeyron [EMAIL PROTECTED] wrote: # Denis Dupeyron [EMAIL PROTECTED] (23 Sep 2007) # Masked for removal in 30 days as per bug #176962. net-print/hpijs Upstream decided to kill hpijs and replace it with hplip quite a good while ago. The replacement is much better and much more usable. So, net-print/hpijs has been masked for removal in 30 days. Please use hplip instead, or have your lawyer talk to my lawyer about why you would still need hpijs. Gone, as promised. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Good-bye
Seemant, On Nov 24, 2007 6:39 PM, Seemant Kulleen [EMAIL PROTECTED] wrote: The time has finally come for me to resign from Gentoo. I've been meaning to do it for many months now, but the logistics took a little bit of time. Effective Monday, Nov. 26, I will no longer consider myself an official Gentoo developer. This would have been a shock if we hadn't discussed this a few months ago already. Gentoo will miss you, and I will miss you. You were one of the unfortunately rare among us who could see and care about the human being that a dev is. Take care. I'll see you around on irc. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-wireless/hostapd: ChangeLog hostapd-0.4.9.ebuild hostapd-0.6.1.ebuild hostapd-0.6.0.ebuild
On Dec 11, 2007 6:03 AM, Mike Frysinger [EMAIL PROTECTED] wrote:
On Monday 10 December 2007, Donnie Berkholz wrote:
{
...
echo CONFIG_EAP_SAKE=y
...
} ${CONFIG}
cat -EOF ${CONFIG}
...
CONFIG_EAP_SAKE=y
...
EOF
-mike
Mike,
Is what you are suggesting better ? If so, why ?
Denis, clueless.
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 1:38 AM, Donnie Berkholz [EMAIL PROTECTED] wrote: Here's some other ideas for how to express EAPI. What if we: [..] Stuck ranges into metadata.xml for which EAPIs applied? This is the easiest and most reasonable solution I've heard so far. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
On Dec 20, 2007 12:12 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... Stop guessing, then. You're way off. You apparently do not understand that an assertion without justification has no value in a serious discussion. Even it that has already been explained somewhere else, it may have been interpreted differently by different people (assuming they can find it). And sorry to disappoint you but you're not alway right. You have to give people a chance to contradict you, for your own good. Also, please stop thinking people have the exact same thing in mind as you because that leads to misunderstandings. All of us being different and thinking differently is why we are this good. There's nothing you can do about this, it's human nature. The day you'll understand all of this you'll be a much better dev and human being in general. And this day, working with you will be lots of fun. Too bad you were late when the specification for Man was written, because it seems we would have been much better than we are, and it would have been easier for you now. Denis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New developer : Richard Freeman (rich0)
After a long and bumpy ride, concluded by a very BOFH-esque LDAP replication failure, we're on it (thanks Robin, by the way), it's my pleasure to announce that Richard Freeman (rich0) is a new Gentoo developer. Richard has been an amd64 AT for some time already, and so will join the amd64 team. His most notable prowess as an ebuild developer is to be trying to sort out the mess that Eternal Lands is. Richard is married and has two children. For a living he works at a pharma where he manages moderately large projects from a business perspective. He says he mainly focuses on requirements, design, interface, training, procedures, validation/testing/QA/reg compliance, etc... I would like to thank Markus Ullmann (jokey) for taking over the mentoring of Richard after his original mentor left us. So please everybody, give a warm welcome to Richard. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Packages up for grabs
On Dec 25, 2007 7:19 PM, Christian Heim [EMAIL PROTECTED] wrote: - media-gfx/f-spot I'll adopt this one if nobody wants it. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Running a script to remove useless deps like virtual/libc from ebuilds
On Dec 30, 2007 6:50 PM, Petteri Räty [EMAIL PROTECTED] wrote: I have a script coming up that can remove virtual/libc dependencies from ebuilds automatically but can this be done safely for all ebuilds are are there ebuilds in system that really need this dep for stage building etc? FWIW: However, packages which are included in the system target, or are dependencies of system target packages, should generally include a complete dependency list (excluding bootstrap packages). This makes emerge -e system possible when installing from a stage 1 or stage 2 tarball. From the last paragraph on implicit dependencies in the devmanual at: http://devmanual.gentoo.org/general-concepts/dependencies/index.html Are there other deps to like this that could be removed? At least sys-libs/zlib could be one. I suppose all packages in /usr/portage/profiles/base/packages are suitable candidates. And maybe profile-specific implicit dependencies on profile-specific packages too, but those would be more complicated to locate. Denis.
Re: [gentoo-dev] USE flag documentation
I like the overall idea. I will comment the first proposed alternative as this is the one that makes the most sense in my opinion. Having one global use.xml where the default definitions are, and then using metadata.xml for each package to override the USE flag definition. With 's/default definitions/global USE flag definitions/' and 's/override the USE flag definition/define the local USE flags/' I would be even happier. Global USE flags should be defined in a central place and never be overridden. Local flags should be defined locally i.e. in the package subdirectory. I'd even go as far as adding that metadata.xml could include some clarifications/specifics/notes/warnings/whatever about a global USE flag for a given package, but that should not be a redefinition of the global USE flag. This would be appended by third party tools to complement the definition of the global USE flag in the context of that particular package. Problems with this approach include... * Easy to duplicate USE flags since we don't have a central repository for them. I'm not following you here. We'd have a central use.xml, so what do you mean ? And it's OK for local flags to be conflicting or duplicated since they're local. Lots of small files to go and parse to get the full picture of the tree. This can be cached. Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] USE flag documentation
On Dec 31, 2007 3:30 PM, Marius Mauch [EMAIL PROTECTED] wrote: What benefit does use.xml have over use.desc? [...] No need to change the format of use.desc Anything that would enable us to document with more than a few words, which is what we're practically limited to with the current format of use.desc, would help. The currently available documentation on USE flags is clearly insufficient, maybe not for you and me and other devs, but for the majority of our users. Note that this is not the same as optionally adding more specific documentation on a global flag in the metadata.xml of a package. and get rid of the stupid separation of local and global flags Good idea. How do you plan to cope with the (currently) local USE flag conflicts though ? Denis. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Last rites: some sci-mathematics packages
On Jan 4, 2008 1:30 PM, Sébastien Fabbro [EMAIL PROTECTED] wrote:
sci-mathematics/ksimus-{boolean,datarecorder,floatingpoint}:
unmaintained upstream since 2003, see bug #157577
Replacements: unknown
Scilab's Scicos ? Not a direct replacement, but there are some similarities.
Denis.
Re: [gentoo-dev] Projects and subproject status
On Jan 9, 2008 1:12 PM, Petteri Räty [EMAIL PROTECTED] wrote: Recruiters About the stuff I'm involved: Are we fine? If Calchan agrees, we are fine. I'm taking care of recruits as fast as I can. I figure any time I spend for the recruiters project is worth a lot more than the same time spent on fixing dev-embedded, sci-electronics or other exotic ebuilds I usually maintain. The good news is I'm close to being able to keep up, i.e. there is very little backlog if any. The bad news is that we'd need to recruit more, and if an additional flow of recruits were to arrive (and that would be welcome) a backlog would certainly start to build up. Also I'm traveling more than I used to (and would like) nowadays, and I'm going to move to the US this summer. So you should expect some offlineness from my part for a few months while I swim across the pond. What are we going to do: Keep going as usual. All in all, we'd need an additional recruiter. Candidates are welcome, but you should know that although it is a very gratifying job, it takes a lot of time and dedication if you want to do it properly. Each recruit takes me anywhere between 6 and 12 hours depending on how many gaps I have to fill. We need as many recruits as possible, but need to have them of sufficient quality. One way to go is to reject those that aren't good enough, and another is to bring as many as you can to a level where they can be useful. I much prefer the latter because I don't think we can afford the former. We would also need to attract more recruits. I'm doing my best to relay queries from potential recruits to various teams and projects, but I'm afraid to say it's seldom that these are answered. So please, whoever you are and even if you're not a project/team leader, next time you're forwarded such mail by me please reply to the user's queries. At the very least you should politely decline the offer. And mentoring will take you some time, but it's time well invested for the future of your project. Finally, if you're a mentor, or are considering mentoring somebody, do not hesitate to contact us in case you have any questions. I have tried to update our documentation recently, so you'll find valuable practical information in there although more could be needed (suggestions welcome). And do not hesitate to go hunting for recruits instead of complaining you don't have enough time managing your Gentoo stuff. For that too we'll be happy to advise. Happy new year to each one of you. Denis.
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-print/hplip: hplip-2.7.10.ebuild ChangeLog hplip-2.7.12.ebuild hplip-2.7.12-r1.ebuild
On Jan 14, 2008 6:39 AM, Donnie Berkholz [EMAIL PROTECTED] wrote:
On 15:08 Sun 13 Jan , Denis Dupeyron (calchan) wrote:
1.1 net-print/hplip/hplip-2.7.12-r1.ebuild
# avoid collisions with cups-1.2 compat symlinks
if [ -e ${ROOT}/usr/lib/cups/backend/hp ] [ -e
${ROOT}/usr/libexec/cups/backend/hp ]; then
rm -f ${ROOT}/usr/libexec/cups/backend/hp{,fax};
fi
This deletion should probably happen in pkg_preinst() instead, so that a
compilation failure doesn't result in changes to the filesystem.
Good point, thanks. I changed it.
Denis.
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Packages needing new maintainers, redux
On Jan 14, 2008 4:12 AM, Robin H. Johnson [EMAIL PROTECTED] wrote: Networking, admin tool for some networked printers and JetDirect-style adapter boxes: net-print/npadmin printing herd, can you take this? Sure, but as long as none of us as such hardware we can only do basic maintenance. This is a not-so-hidden call to anybody with this and other printing hardware to join the net-print herd to help us. Hardware, programming PIC embedded microcontrollers (the herd might end up with these, but somebody with the hardware to use them would be nice): dev-embedded/icdprog dev-embedded/pikdev dev-embedded/xgpasm Sent to dev-embedded herd. Same here. I'm happy fixing and bumping stuff in dev-embedded but I do not have access to any hardware anymore. So anyone is welcome to help and join this herd too. Denis. -- gentoo-dev@lists.gentoo.org mailing list
