Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Thu, Jul 27, 2017 at 6:41 PM, Rich Freemanwrote: > > When in the last 16 years was this 2 year period of running stable? > The general state of QA has varied quite a bit over that time. > I would say 3 or 4 years ago, roughly. > running unstable systemd has been Running unstable doesn't mean being stupid. > If unstable never breaks chances are we aren't actually using it for its > intended purpose, not that we > should be deliberately breaking things. There's this idea that unstable should break. But the initial idea was that unstable is what should be sent straight to stable, barring the occasional mistake. Unstable was never meant for ebuilds in development and very much in flux because of that. That's what package masks are for.
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovichwrote: > TL;DR;TL;DR: > [...] Here's a data point you may, or may not, find relevant. in 16 years of using Gentoo exclusively, the only one time I used stable on one machine for about 2 years it ended up being much more of a pain than unstable. Actually, I can't say I have anything to complain about unstable. On my critical machines I snapshot the system subvolume before I update. I can't remember the last time I had to roll back. I'm sure most will disagree with me but since you're indirectly asking for my opinion here it is: I think people working on stable are wasting their time. But who am I to stop them...
Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?
On Mon, Oct 24, 2016 at 5:21 PM, Matthias Maierwrote: > And I see absolutely no harm in explicitly annotating the actual > copyright in gentoo ebuilds. It seems like a simple and practical enough way to go. However, one of the arguments going for assigning copyright to the Gentoo foundation at the time we discussed it is that it offers some level of legal protection to the developer or external contributor. I have first hand experience of how abusive lawyers can sue you for totally invalid IP-related reasons and ruin your life. I've been fighting exactly that for almost 10 years now. So I certainly appreciate the comfort that assigning copyright of my Gentoo work to the foundation provides me. Having grown up in Europe I can see why people would think this could never happen to them, but living in the US has taught me differently. That said, we could always make it possible for the developer to voluntarily assign copyright to the foundation if (s)he so desires. And I would certainly do that for myself. Calchan.
Re: [gentoo-dev] games.eclass policy
On Wed, Feb 17, 2016 at 11:38 AM, Michał Górnywrote: > > Well, maybe it's because you can talk to Python team, discuss and not > get ignored by them. We've already established the same is true for the games team. I'm a living example of it and I can't imagine I'm the only one. > Unlike games team members who believe it's best to > ignore certain developers. I certainly hope we can still ignore abrasive developers since it's been proven many times that it's the best way to deal with them. So, you don't answer my question. Or rather, you answer with a specious statement. Since you're being unusually shy I will say what you're trying hard not so say. There are actually first-class projects catered for by first-class developers, and those can set rules like the mandatory use of an eclass and actually enforce them. Then there are second-class projects and developers who can do the same as long as it doesn't bother the first-class people. Second-class developers, often working quietly and steadily, not wasting their time on mailing-lists like I just did, can see their projects trampled over at any time for the mere reason that they were trying to keep their business in order, just like first-class developers do. Thank you for the clarification. Denis.
Re: [gentoo-dev] games.eclass policy
On Wed, Feb 17, 2016 at 10:33 AM, Michał Górnywrote: > I was stating the apparent state of facts. If people are told they're > supposed to go with games team, use their eclass, follow their > policies, that's how it looks to people. That's an entirely different point from the one I was making. But I'll entertain you anyway. All teams have rules and enforce them. If I commit, say, a python package and I don't use the python eclass, I'm sure to get a bug filed telling me to do so, a python team-member forcing the change on me if I refuse, this escalating to comrel if I complain or reverse the change, etc... So why would it be OK for the python team to coerce and not OK for the games team? In other words, why would the games team have less right to good housekeeping than the python team? Here python is just an example, I could have picked any other team. Denis.
Re: [gentoo-dev] games.eclass policy
On Wed, Feb 17, 2016 at 9:22 AM, Michał Górny <mgo...@gentoo.org> wrote: > On Wed, 17 Feb 2016 08:32:53 -0700 > Denis Dupeyron <calc...@gentoo.org> wrote: > > Not true. I've been maintaining games for a decade and have never been > on > > the team. > > Quoting the previous documentation of games.eclass [...] > I'm not seeing the connection you make between the documentation of an eclass and the fact that I have been maintaining games for ten years without being part of the games team. From here it looks like you're typing faster than you can read. Denis.
Re: [gentoo-dev] games.eclass policy
On Wed, Feb 17, 2016 at 12:39 AM, Michał Górnywrote: > developers who did what they cared about and ignored everything and > everyone else. > I don't know if I'm an exception to the rule, but I've always had fruitful interactions with the games team. I never felt they ignored me. > games team sole claim to games in gentoo. > Not true. I've been maintaining games for a decade and have never been on the team. Denis.
[gentoo-dev] It is GSoC season again
Google Summer of Code 2016 is starting. If you are a student please be patient. Your time will come soon, at which point we'll be able to answer all your questions. In this initial phase the audience is project mentors. Note that you do not need to be a Gentoo developer to be a mentor. While we are finalizing the application, we need all of you to submit your project ideas before the end of next week (February 19th). To do so you should go to [1] and follow the instructions in the "Ideas" section. If you proposed an idea last year and would like to propose it again for this year, you can look it up at [2] and add it to [1]. Or you can just tell us and we will do it for you. Don't hesitate to add an idea even it isn't totally fleshed out; we will help you fill in the blanks. A project represents 3 months of full-time work for a student. A good rule of thumb is that it should take you between 2 and 4 weeks to complete depending on how expert you are in the field. You can also have a look at [2] for examples. If you would like to be a mentor for this year please tell us sooner rather than later. You can be a mentor following up with students while they're working on their project, or you can be an expert-mentor in a specific field who will be called in to advise on an as-needed basis (or maybe never). We will also need people to help us review project proposals. In case you can help in any capacity don't hesitate to contact us. GSoC is seriously fun! If you want to reach us or have any questions about any of the above, the easiest way is to ping Calchan or rafaelmartins in the #gentoo-soc channel on Freenode. Thanks, Calchan. [1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2016/Ideas [2] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2015/Ideas
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, Jul 28, 2014 at 6:49 PM, Alex Xu alex_y...@yahoo.ca wrote: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/x265/x265-.ebuild?revision=1.9view=markup#l9 Thanks, Alex. This makes more sense now. Denis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, Jul 28, 2014 at 8:41 PM, Duncan 1i5t5.dun...@cox.net wrote: AFAIK, gentoo policy is that live ebuilds should always be masked so as never to be automatically pulled in without a deliberate unmasking of the live ebuild, but whether that's masked due to lack of keywords (ebuild), or due to hard-mask (package.mask) is I believe up to the maintainer. The policy apparently disappeared in the shuffling of documentation which occurred over the years. But here is what I was instructed to teach recruits back when I became a recruiter in 2006 or 2007, and what competent developers have been doing since even before I was a developer: The package.mask file is only for temporary masking, even if more or less long term. Anything that should be permanently masked has no place in the tree. Live ebuilds should not be keyworded, reflecting the fact that the code they're pulling has not be tested for any architecture due to it being live. Moreover, live ebuilds should not be masked as this results in unnecessary cruft in the package.mask file. Denis.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/x265: x265-1.0.ebuild ChangeLog x265-1.2.ebuild x265-0.8.ebuild
On Mon, Jul 28, 2014 at 12:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: x265-1.2.ebuild:KEYWORDS=~amd64 ~arm ~x86 x265-1.3.ebuild:KEYWORDS=~amd64 ~x86 x265-.ebuild:KEYWORDS=~amd64 ~x86 As in... You forgot to add ~arm to -.ebuild Wait, what? Live ebuilds are keyworded now? Denis.
[gentoo-dev] Re: [gentoo-dev-announce] last rites: games-fps/postal2mp-demo
On Tue, Jul 8, 2014 at 9:48 AM, Ian Stakenvicius a...@gentoo.org wrote: Last rites cancelled; found a version bump'ed distfile via icculus, so this one can live a little longer. I have once asked Robin to archive the distfiles for a commercial package which has RESTRICT=mirror. My reasoning at the time was that if upstream disappears there's a good chance, depending on why that happens, we can qualify the software as abandonware and the no mirror restriction may become moot. At that point we could push the distfiles to our mirrors. Note that this particular software still requires original installation media (on top of the 1GB+ distfiles) and a minimum of 1 but up to 3 valid license keys to install and then run. My point here is we could do this preemptively and more or less systematically in order to avoid being in the situation above. This could even be easily automated. The worst that can happen is we archive a few distfiles for nothing, which isn't a big price to pay. Denis.
Re: [gentoo-dev] The request to abolish games team policy
On Mon, Jul 14, 2014 at 12:11 PM, hasufell hasuf...@gentoo.org wrote: a) I'm not sure if I want to be in a team where vapier is lead. The only position you don't want vapier in is behind you. He humps. Denis.
Re: [gentoo-dev] Re: The request to abolish games team policy
On Mon, Jul 14, 2014 at 12:10 PM, hasufell hasuf...@gentoo.org wrote: People often reply aggressively to unrequested reviews People often replay aggressively when they feel aggressed. Food for thought? Denis.
Re: [gentoo-dev] Re: last rites: games-fps/postal2mp-demo
On Wed, Jul 16, 2014 at 12:22 PM, Alexander Berntsen berna...@gentoo.org wrote: Ulrich is right. Abandonware just means orphaned works -- i.e. the copyright holder hasn't sued anyone yet. Gentoo should not have anything to do with this. I agree with you and Ulrich. That was a very poor choice of word from my part and not what I wanted to say. I didn't mean we should distribute distfiles without consent, but back them up to a hidden place while it is possible to do so. Obtaining consent to mirror updates or linux specific files of a commercial game which is not distributed anymore when asking politely isn't unseen, because often the editor or publisher doesn't care any longer. If you don't backup the files first there is little chance you will get them from the editor exactly because they don't care. Denis.
Re: [gentoo-dev] Re: last rites: games-fps/postal2mp-demo
On Wed, Jul 16, 2014 at 1:28 PM, Ian Stakenvicius a...@gentoo.org wrote: So, RESTRICT=mirror would turn into RESTRICT=officially-dont-mirror-but-actually-do-just-in-case-distfiles-are-dropped-upstream-but-after-we-still-cant-officially-mirror-them-due-to-license-and-copyright-infringement-anyway ? Pretty sure, no matter what, we aren't going to be allowed to host these distfiles, even if the upstream host disappears, even if the company goes under. If we can't get permission to officially mirror the files then the company is active and alive, i don't see how it's likely to get permission after the distfiles/server/company goes away. Either you're trying very hard to not get it or you haven't read my previous email carefully enough. Let me try and be clearer. The packages I'm concerned with have had their distfiles backed up. We're not yet in that situation but the day the publisher stops distributing these distfiles, I'll be ready to send the right email to the (hopefully) right person and hope for the best. I was suggesting we did that more often. And with that I'll stop here, because these childish arguments are not worth any more of my time. Denis.
Re: [gentoo-dev] The request to abolish games team policy
Please do not take this personally. I honestly wonder what all the fuss is about. There are a few games I've helped with over the years and I've never had any trouble at all having my stuff reviewed and accepted. And I'm a lousy ebuild writer. Every time I'd suggest a fix, bump, or new package, and I came with an ebuild, I would get constructive criticism and I could then commit it myself. Not one single time did I get a no. Not once. You had a fix and it was refused? Have you ever considered you may have been doing it wrong? I understand having to have your code reviewed and accepted sounds like an insult to a rock star like you, but that's the way it is in the real world. It is still beyond my understanding that code reviews are not mandatory for anything that is committed in Gentoo. Rich, if I may have a suggestion, it would be that instead of meddling with projects that have been doing their best with what they have for years, and which need praise rather than hindrance, you instead start a project to get people to think positively and accept criticism. The amount of energy that was spent in this thread and many others in pure loss could have gone a long way. Denis.
Re: [gentoo-dev] Thank you
On Wed, Feb 5, 2014 at 11:30 PM, Canek Peláez Valdés can...@gmail.com wrote: Hi. TL;DR, this is basically just a THANK YOU to the Gentoo devs This is totally unacceptable. I demand you take your thank-yous back. Who do you think you are to thank us like this, even with valid reasons? Good manners will not be tolerated on this mailing-list. We have been trying very hard all these years to slack as much as possible. Your public insinuations that any work gets done in Gentoo are outright insulting. Since you have been using Gentoo for such a long time, I dare you to try and become a developer to see if you can compare to us. A good day to you nonetheless, sir. Denis.
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sat, Jan 18, 2014 at 10:02 PM, William Hubbs willi...@gentoo.org wrote: This is nothing new; the qa team has requested that commit rights be suspended before. I am just proposing that we actually add the parts of the old patch to the glep that spell out when and how this can happen. Thoughts? Yes, thoughts, absolutely. Asking for QA to be at the same time judge, party and executioner. Need I say more? Denis.
Re: [gentoo-dev] rfc: formally allow qa to suspend commit rights
On Sun, Jan 19, 2014 at 6:01 PM, Tom Wijsman tom...@gentoo.org wrote: It is more of a Do we want QA to delegate this through ComRel or not?. Actually, no. What it is is a Subject was thoroughly discussed in the past, and a decision was made. More than once, in fact. What basis do you have that would warrant more bilkeshedding on this subject? It may sound crazy, but it isn't entirely impossible that decisions made in the past were not made lightly. It's also not entirely impossible that one of the reasons such decisions are made is so that people can stop rehashing the same topics over and over again and focus on more useful and fun topics. Denis.
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] Recruitment process is moving back to quizzes
On Sun, Jul 15, 2012 at 9:08 AM, Ben de Groot yng...@gentoo.org wrote: Certainly. But it is likely much more interesting work and has considerably more impact. The mentoring period and the review have considerable impact too. Whether you think one is more important than the other depends on you thinking short or long term. The quizzes are no more than a tool, and us arguing over them shows we're focusing on the wrong things. Denis.
[gentoo-dev] Re: [gentoo-dev-announce] Gentoo's plan to remove .la files
On Sat, Oct 30, 2010 at 10:25 PM, Jorge Manuel B. S. Vicetto jmbsvice...@gentoo.org wrote: As decided in the last council's meeting, following the recent discussions about .la files removal, I'm sending an email to this list with a proposal for a plan to address this issue. 1- Why is a proposal sent to gentoo-dev-announce? Shouldn't that rather be worked out before being announced? Or is there some context that the ordinary user or developer is missing? 2- Sending to both gentoo-dev and gentoo-council makes sure that this splits into twice as many threads as it would have. Good luck with merging them after that. 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] 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] 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.
[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] 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.
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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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.
[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.
[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.
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.
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] 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] 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] 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] 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] 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] 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] 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
[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] 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.
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] 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] 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] 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] 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] 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] 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] 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] 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] sandbox-1.3.x testing for stable
On Thu, Feb 12, 2009 at 7:56 AM, Mike Frysinger vap...@gentoo.org wrote: i'm feelin pretty good about the latest sandbox-1.3.x (little stiffy even). little stiffy only ? That's OK, you're just getting old. Please come see me for your free prescription and directions for use of the blue pills. i'd like to have it so that when i meet my bus, the next sucker can pick up the project and run with it w/out making too much of a mess. Your mom told me last night that she won't be taking you back. You're stuck with us. Denis.
Re: [gentoo-dev] new categories:
On Tue, Feb 3, 2009 at 11:47 AM, George Shapovalov geo...@gentoo.org wrote: Besides, in my opinion, the ability to see what's there in at least minimally categorized way without having to resort to using some special tools or going to some website is worht something. In this vain I was proposing going the opposite direction - to allow arbitrary nesting of categories, like going sci-math - sci/math and deeper (then packages would naturally be specified by FQEN - fully qualified ebuild names). Its not like tree walker would be the most complex part of code in portage.. Actually we'd want both tags and nesting. They don't address the same issue. Arbitrary nesting of categories allows better management and storing of ebuilds. It could also allow a meta-ebuild to depend on a whole subcategory to ease maintenance of said meta-ebuild. It's more a developer's feature. Tags allow ebuilds to appear as being pertinent to more (sub-)categories than just the one they're stored into. It may help some of us locate packages they need in a better and/or faster way. It's more of a user's feature. Denis.
Re: [gentoo-dev] The Plethora of Patches
On Thu, Aug 14, 2008 at 4:17 AM, Andrew D Kirch [EMAIL PROTECTED] wrote: [...] Looks like you counted the number of files in the files/ subdirectories. Not all of these are patches. Also, you probably forgot to count seds, as some of us use sed more than patches. Oh, and like Jeremy was hinting, please contact QA. They need somebody like you. Denis.
Re: [gentoo-dev] Re: Retirement
On Mon, Aug 11, 2008 at 1:18 AM, Nikos Chantziaras [EMAIL PROTECTED] wrote: They always say that stuff but never bother explaining what the direction they wish for actually is. As a user I get the impression that there's some kind of evil Cabal. Most of the Gentoo developer population is made of young males with a natural tendency to overreaction and suboptimal communication skills (and I'm not implying it's the case of the original poster). So, if I were you, I wouldn't bother too much to read in between the lines of these retirement messages. Denis.
[gentoo-dev] Interesting article from the Times Magazine
From the Times Magazine : http://www.nytimes.com/2008/08/03/magazine/03trolls-t.html It mostly doesn't apply to us as a community (hopefully), but one paragraph is especially interesting. In 1981, [Jon Postel] formulated what's known as Postel's Law: Be conservative in what you do; be liberal in what you accept from others. Originally intended to foster interoperability, the ability of multiple computer systems to understand one another, Postel's Law is now recognized as having wider applications. To build a robust global network with no central authority, engineers were encouraged to write code that could speak as clearly as possible yet listen to the widest possible range of other speakers, including those who do not conform perfectly to the rules of the road. The human equivalent of this robustness is a combination of eloquence and tolerance — the spirit of good conversation. Trolls embody the opposite principle. They are liberal in what they do and conservative in what they construe as acceptable behavior from others. You, the troll says, are not worthy of my understanding; I, therefore, will do everything I can to confound you. I'd add that trolling isn't always conscious, so everyone of us is potentially somebody else's troll. My personal trick is that I always re-read my posts as if they were addressed to myself on a bad hair day. Denis.
Re: [gentoo-dev] GLEP 55 - The Long Thread
On Tue, Jun 10, 2008 at 4:51 PM, Doug Goldstein [EMAIL PROTECTED] wrote: There's a lot to be said about being stuck in the grand design mindset. I know many Gentoo, Portage, Exherbo, and Paludis developers are clearly coming to that point in their programming careers based on the comments on this thread and other threads. I would just like to caution everyone that they really need to get past this plateau in their programming careers and get on to the real mindset that matters in the future. The use case mindset. Georges Clemenceau once said : War is too serious a matter to entrust to military men. There surely is something to be said along these lines about software design and programmers. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
On Thu, Jun 12, 2008 at 10:16 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: Are you seriously suggesting that the portage and pkgcore developers think that they should be able to release a package manager that claims to support an EAPI when it in fact doesn't? Please stop your incessant and gratuitous insinuations. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Mon, Jun 9, 2008 at 10:06 AM, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 09 Jun 2008 09:58:40 +0200 Luca Barbato [EMAIL PROTECTED] wrote: Usually in this category you put everybody that disagrees with you, no matter the topic. And what does that tell you about the average level of response? And what does that tell you about how well you fit this community ? So how, specifically, is PMS wrongly written, and why hasn't anyone who thinks so bothered to provide details? See above. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] A few questions to our nominees
On Sun, Jun 8, 2008 at 12:45 PM, Roy Bamford [EMAIL PROTECTED] wrote: Before the flames start lets consider the Package Manager Specification (PMS) as an example. For this (very black and white) illustration, forget the council discussions to date and imagine that representatives of all three package managers went to council and said in unison We have agreed this specification. Are council really going to start picking holes in it and say no? The council being our global technical lead, I can't see why they wouldn't be allowed to reject an agreed package manager specification or parts of it. If not, why bother electing them at all ? Not that I think that would be a smart move, but that's a different discussion. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Nominations for council
On Tue, Jun 3, 2008 at 7:52 AM, Ferris McCormick [EMAIL PROTECTED] wrote: I think nominations are open. I nominate rane welp zlin Alright. Then I'll nominate all members of the current council. In alphabetical order: amne betelgeuse dberkholz flameeyes jokey lu_zero vapier Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] LaTeX documentation
On Tue, May 13, 2008 at 12:31 AM, Alexis Ballier [EMAIL PROTECTED] wrote: Yeah or maybe they dont need any unusual fonts; its probably sane to set VARTEXFONTS regardless. Probably it'd be worth adding a latex eclass that would just contain: VARTEXFONTS=${T}/fonts and inherit it from any package calling latex to avoid code duplication (like e.g. the mono eclass do). What do you think ? As long as we can't easily remove eclasses I'd rather we don't make a new one for such trivial needs. Unless I've missed something and they can easily be removed nowadays. Also, overloading the environment with global variables should be avoided when possible. In that case I'd recommend the VARTEXFONTS variable be passed with the emake command or whatever needs latex in the ebuild. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Bug wrangling
On Mon, May 12, 2008 at 2:10 PM, Ferris McCormick [EMAIL PROTECTED] wrote: This only occured since we have no full-time bug-wrangler anymore. Was anyone successful to contact him, yet? I am told he should be back sometime soon, like today. Apparently someone is in contact with him. That he comes back or not is of no importance to bug wrangling. Or at least it should be. It is a mistake to solely rely on a developer for such a task. Developers come and go without warning, he just proved it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also, one single developer handling this puts him/her in such a prominent position that it is bad for him/her, our users, other developers and the entire project. We had too many examples of this. Denis. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] New developer : Markus Duft (mduft)
It's my pleasure to introduce Markus Duft (mduft) as a new developer. He will go among us under the name of mduft, and will work in the Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that means Gentoo on Win32. Markus lives with his wife and daughter in Graz, Austria. He seems to have many hobbies like reading fantasy novels, building remote-controlled model planes, crashing remote-controlled model planes, and last but not least, playing good old board games with his wife. Err... Markus, we are a mature audience here, so no need to call that good old board games, OK ? He shares an office at work with Michael Haubenwallner (haubi), who is strangely also a member of the Gentoo/alt project. Please everybody, give a very warm welcome to mduft. Denis. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] New developer : Chris Henhawke (bunder)
It's my pleasure to introduce Chris Henhawke as a new developer among us. He is a forums veteran where he goes under the name of bunder, and has been a moderator there for about 9 months. Chris lives in Hamilton, Ontario, and is a computer operator who does maintenance and support. During the interrogation^Wreview, he wasn't very talkative but did confess an addiction to the Gentoo forums and smoking. His insistence to deny any other type of addiction or even alien rape was at the very least suspicious. Unfortunately I was out of pentothal (SpankY drank it all this morning for breakfast) so I couldn't investigate any further. Please everybody, give a very warm welcome to bunder. Denis. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Return of a developer : Josh Glover (jmglov)
It's my pleasure to announce the return of Josh Glover (jmglov) as a Gentoo developer. Josh will resume his work on CJK and miscellaneous packages. Josh works as a Software Development Engineer for Amazon, developing the mobile phone version of the retail website. He also serves as Listmaster for the Tokyo Linux Users Group. Josh is married and has a son. He comes from this promising new world which knows of no borders. He is originally a USian, lives in Japan and his wife is Bulgarian. He enjoys sports of all kinds, and is especially addicted to football (that's soccer to you guys on the other side of the pond). He likes being outdoors, reading, writing (both fiction and essays), and traveling with his wife and son. All is not lost though as he also enjoys drinking beer. So please everybody give a warm re-welcome to Josh. Denis. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: gentoo-x86 commit in app-office/homebank: metadata.xml ChangeLog homebank-3.7.ebuild Manifest
On Tue, Apr 1, 2008 at 3:37 PM, Tiziano Müller [EMAIL PROTECTED] wrote: eautoconf is enough. Sorry about that. Fixed. Denis. ���^�X�����(��j)b�b�
[gentoo-dev] Last rites: sci-libs/libgdgeda
# Denis Dupeyron [EMAIL PROTECTED] (22 Mar 2008) # Not needed anymore. Was only used by old versions of # sci-libs/libgeda which were just punted. Will be removed # in 30 days. sci-libs/libgdgeda -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last rites: sci-electronics/lard
It finally happened. Last version was 5 years ago or so. From package.mask: # Denis Dupeyron [EMAIL PROTECTED] (15 Mar 2008) # Masked for removal in 30 days. Requires Tcl 8.3 which # isn't in the tree anymore. See bugs 172356 and 173467. sci-electronics/lard -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
On Fri, Mar 14, 2008 at 8:14 AM, Rémi Cardona [EMAIL PROTECTED] wrote: - the gnome2 eclass now has a pkg_preinst, if you do multiple inherits, make sure that gnome2_pkg_preinst is called too. The _games_eclass_ is one of those. [...] *Please* review these eclasses because with a simple grep, I could find over _1000_packages_ that inherited gnome2.eclass. But many more use other eclasses that depend on gnome2-utils. In case that's of any help, the ugly thing below should lists all eclasses that export pkg_preinst: trillian ~ # for ECLASS_ECLASS in /usr/portage/eclass/*.eclass; do echo ${ECLASS_ECLASS}:$(sed -e :a -e '/\\$/N; s/\\\n//; ta' ${ECLASS_ECLASS} | grep EXPORT_FUNCTIONS); done | grep pkg_preinst | cut -d . -f 1 | cut -d / -f 5 common-lisp games kde kernel-2 kernel linux-mod mount-boot myspell mysql perl-module subversion tetex-3 toolchain vmware x-modular And the even uglier thing below should list all ebuilds that inherit a gnome2* eclass and any of the above: trillian ~ # for ECLASS in $(for ECLASS_ECLASS in /usr/portage/eclass/*.eclass; do echo ${ECLASS_ECLASS}:$(sed -e :a -e '/\\$/N; s/\\\n//; ta' ${ECLASS_ECLASS} | grep EXPORT_FUNCTIONS); done | grep pkg_preinst | cut -d . -f 1 | cut -d / -f 5); do qgrep -H inherit | grep ${ECLASS} | grep gnome2; done | sort | uniq games-arcade/blobwars/blobwars-1.07.ebuild:inherit eutils gnome2-utils games games-arcade/blobwars/blobwars-1.08.ebuild:inherit eutils gnome2-utils games games-board/gnome-mastermind/gnome-mastermind-0.3.ebuild:inherit eutils games gnome2 games-board/gnono/gnono-1.9.1.ebuild:inherit autotools eutils gnome2-utils games media-video/vlc/vlc-0.8.6e.ebuild:inherit eutils wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins media-video/vlc/vlc-0.9.0_alpha20080117.ebuild:inherit eutils wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins qt4 flag-o-matic media-video/vlc/vlc-0.9.0_alpha20080228.ebuild:inherit eutils wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins qt4 flag-o-matic media-video/vlc/vlc-0.9.0_alpha20080309.ebuild:inherit eutils wxwidgets multilib autotools toolchain-funcs gnome2 nsplugins qt4 flag-o-matic net-im/pidgin/pidgin-2.3.1.ebuild:inherit flag-o-matic eutils toolchain-funcs multilib perl-app gnome2 net-im/pidgin/pidgin-2.4.0.ebuild:inherit flag-o-matic eutils toolchain-funcs multilib perl-app gnome2 sci-astronomy/celestia/celestia-1.4.1-r2.ebuild:inherit eutils flag-o-matic gnome2 kde-functions autotools sci-astronomy/celestia/celestia-1.5.0.ebuild:inherit eutils flag-o-matic gnome2 kde-functions autotools If you remove from that list vlc, pidgin and celestia which are false positives, that leaves us: games-arcade/blobwars/blobwars-1.07.ebuild games-arcade/blobwars/blobwars-1.08.ebuild games-board/gnome-mastermind/gnome-mastermind-0.3.ebuild games-board/gnono/gnono-1.9.1.ebuild If I didn't screw up that shouldn't take long to check. Denis.
Re: [gentoo-dev] [RFC] Major changes to the Gnome2 Eclasses
On Fri, Mar 14, 2008 at 11:21 AM, Rémi Cardona [EMAIL PROTECTED] wrote: If you remove from that list vlc, pidgin and celestia which are false positives, that leaves us: Why are they false positives? They include the gnome2 eclass and other stuff, I guess they'll be affected too. Because, for example celestia is found by a grep on the inherited kde eclass that's triggered by inheriting kde-functions. And the latter doesn't export pkg_preinst. /me wonders why gnome-games didn't appear in your list, which was the one ebuild I found out broke with the new eclass. The answer is easy: I screwed up. I warned you. ;o) This is due to a combination of the quoting I used in order to remove some of the false positives and apparently something else. Here's the raw output without quoting: trillian ~ # for ECLASS in $(for ECLASS_ECLASS in /usr/portage/eclass/*.eclass; do echo ${ECLASS_ECLASS}:$(sed -e :a -e '/\\$/N; s/\\\n//; ta' ${ECLASS_ECLASS} | grep EXPORT_FUNCTIONS); done | grep pkg_preinst | cut -d . -f 1 | cut -d / -f 5); do qgrep -H inherit | grep gnome2 | grep ${ECLASS} ; done | sort | uniq app-i18n/scim-pinyin/scim-pinyin-0.5.91.ebuild:inherit kde-functions gnome2 dev-db/mysql-gui-tools/mysql-gui-tools-5.0_p12-r2.ebuild:inherit gnome2 eutils flag-o-matic dev-perl/gnome2-canvas/gnome2-canvas-1.002.ebuild:inherit perl-module dev-perl/gnome2-gconf/gnome2-gconf-1.000.ebuild:inherit perl-module dev-perl/gnome2-gconf/gnome2-gconf-1.031.ebuild:inherit perl-module dev-perl/gnome2-gconf/gnome2-gconf-1.032.ebuild:inherit perl-module dev-perl/gnome2-gconf/gnome2-gconf-1.040.ebuild:inherit perl-module dev-perl/gnome2-gconf/gnome2-gconf-1.043.ebuild:inherit perl-module dev-perl/gnome2-perl/gnome2-perl-1.023.ebuild:inherit perl-module dev-perl/gnome2-perl/gnome2-perl-1.040.ebuild:inherit perl-module dev-perl/gnome2-perl/gnome2-perl-1.041.ebuild:inherit perl-module dev-perl/gnome2-print/gnome2-print-0.94.ebuild:inherit perl-module dev-perl/gnome2-print/gnome2-print-1.000.ebuild:inherit perl-module dev-perl/gnome2-vfs-perl/gnome2-vfs-perl-1.041.ebuild:inherit perl-module dev-perl/gnome2-vfs-perl/gnome2-vfs-perl-1.060.ebuild:inherit perl-module dev-perl/gnome2-vfs-perl/gnome2-vfs-perl-1.061.ebuild:inherit perl-module dev-perl/gnome2-wnck/gnome2-wnck-0.11.ebuild:inherit perl-module eutils dev-perl/gnome2-wnck/gnome2-wnck-0.12.ebuild:inherit perl-module eutils dev-perl/gnome2-wnck/gnome2-wnck-0.13.ebuild:inherit perl-module eutils dev-perl/gnome2-wnck/gnome2-wnck-0.14.ebuild:inherit perl-module eutils dev-util/devhelp/devhelp-0.16.1.ebuild:inherit toolchain-funcs gnome2 dev-util/devhelp/devhelp-0.17.ebuild:inherit toolchain-funcs gnome2 python dev-util/devhelp/devhelp-0.18.ebuild:inherit toolchain-funcs gnome2 python dev-util/devhelp/devhelp-0.19.ebuild:inherit toolchain-funcs gnome2 python games-arcade/blobwars/blobwars-1.07.ebuild:inherit eutils gnome2-utils games games-arcade/blobwars/blobwars-1.08.ebuild:inherit eutils gnome2-utils games games-arcade/monkey-bubble/monkey-bubble-0.4.0.ebuild:inherit autotools eutils gnome2 games-board/gamazons/gamazons-0.83.ebuild:inherit gnome2 games-board/gnome-mastermind/gnome-mastermind-0.3.ebuild:inherit eutils games gnome2 games-board/gnono/gnono-1.9.1.ebuild:inherit autotools eutils gnome2-utils games games-board/pioneers/pioneers-0.11.3-r1.ebuild:inherit eutils gnome2 games-board/teg/teg-0.11.2.ebuild:inherit gnome2 games-kids/gmult/gmult-4.2.ebuild:inherit gnome2 games-kids/gmult/gmult-5.3.ebuild:inherit gnome2 games-mud/gnome-mud/gnome-mud-0.10.7.ebuild:inherit gnome2 games games-puzzle/atomix/atomix-2.14.0.ebuild:inherit gnome2 games-puzzle/glightoff/glightoff-1.0.0.ebuild:inherit gnome2 games-puzzle/gtetrinet/gtetrinet-0.7.11.ebuild:inherit gnome2 games games-puzzle/skoosh/skoosh-2.5.0.ebuild:inherit gnome2 games-strategy/gwp/gwp-0.4.0-r2.ebuild:inherit eutils gnome2 gnome-extra/drwright/drwright-0.17.ebuild:inherit gnome2 flag-o-matic toolchain-funcs gnome-extra/gnome-games-extra-data/gnome-games-extra-data-2.12.0.ebuild:inherit gnome2 gnome-extra/gnome-games-extra-data/gnome-games-extra-data-2.14.0.ebuild:inherit gnome2 gnome-extra/gnome-games-extra-data/gnome-games-extra-data-2.20.0.ebuild:inherit gnome2 gnome-extra/gnome-games/gnome-games-2.18.2.1.ebuild:inherit games eutils gnome2 autotools gnome-extra/gnome-games/gnome-games-2.18.2.1.ebuild:# make sure games is inherited first so that the gnome2 gnome-extra/gnome-games/gnome-games-2.20.3.ebuild:inherit games eutils gnome2 python autotools virtualx gnome-extra/gnome-games/gnome-games-2.20.3.ebuild:# make sure games is inherited first so that the gnome2 media-gfx/comix/comix-3.6.3.ebuild:inherit toolchain-funcs gnome2 media-gfx/comix/comix-3.6.4.ebuild:inherit toolchain-funcs gnome2 media-video/jubler/jubler-3.4.0.ebuild:inherit gnome2 eutils java-pkg-2 java-utils-2 java-ant-2 toolchain-funcs media-video/jubler/jubler-3.4.1.ebuild:inherit gnome2 eutils java-pkg-2 java-ant-2 toolchain-funcs
Re: [gentoo-dev] Help offered - Portage tree
On Thu, Mar 13, 2008 at 12:35 AM, Fabio Erculiani [EMAIL PROTECTED] wrote: After having discussed with one of your dev about it, he suggested me to ask here looking for a mentor. If there's anything I can do, I'm ready. On Thu, Mar 13, 2008 at 12:57 AM, Fabio Erculiani [EMAIL PROTECTED] wrote: I know what you mean, but take into account I don't have much time left for the reporting. What I ask is [...] getting me able to fix stuff So you don't have time to file bugs but you would have time to fix them ? Interesting... In any case, we require users to have a consistent history of helping the project before they are considered for recruitment. What you are doing for Sabayon is great but it can't be taken into account. Please find below some information that may be useful to get you started. There are many ways you can help. Two good ways to start helping out are proposing solutions for bugs [1] and contributing to an overlay [2] like Sunrise for example [3]. There is more information on how to get involved with overlay development at [4]. When your contributions become significant enough, developers may contact you (or you can contact them). You may also want to have a look at the staffing needs page [5]. You will need to read the Gentoo Documentation Resources [6], and more specifically the Gentoo Developer Handbook [7] and the Gentoo Development Guide [8]. Another way to help, especially for non-technical projects, is to contact people directly [9]. Be aware that they can be away though, so be patient, try others on the same project, and finally get back to us in case you fail to reach anybody. Do not hesitate to contact recruiters in the future in case you need more information. Best regards, Denis. [1] http://bugs.gentoo.org/ [2] http://overlays.gentoo.org/ [3] http://overlays.gentoo.org/proj/sunrise/ [4] http://www.gentoo.org/proj/en/overlays/userguide.xml#doc_chap3 [5] http://www.gentoo.org/proj/en/devrel/staffing-needs/ [6] http://www.gentoo.org/doc/en/index.xml?catid=gentoodev [7] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml [8] http://devmanual.gentoo.org/ [9] http://www.gentoo.org/proj/en/index.xml?showlevel=2 -- gentoo-dev@lists.gentoo.org mailing list