Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
On Tuesday 02 June 2009 06:15:43 Doug Goldstein wrote: > All, > > The current council meetings have gotten completely out of hand for > weeks meetings have become nothing more then a continuation of the > senseless bicker-fest that have become the e-mail threads on GLEP54, > GLEP55, and EAPI-3 without any real progress or sense coming of them. > It's taken me a little bit to step up and put a stop to it but I fully > intend on putting a stop to it. You have my full support for that. > The point of the council meetings is > to bring up a topic and decide on its merits whether it should be > brought into the Gentoo Project or not. I'd say the point is to decide on technical issues, not just limited to adding new things. [snip] > I propose the following > changes be instituted before the meeting and happen through the > meeting: [snip] A bit harsh maybe, and needs everyone involved to agree to it to work, but that looks like a great plan to allow council to actually decide on issues. > If people like this, great. If people don't, then I can feel comforted > that I spoke my piece about what I want to see the council become and > people don't share the same vision as me. If people don't want to play by the rules they can go play in their own sandbox. We're a large community that needs a certain amount of structure and rules to work efficiently, anyone trying to sabotage that should be sanctioned. I don't mean to imply that we need more rules (that never works) but better rules and someone to enforce them. Just my two Groschen, Patrick
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
(items 1 through 2b): > ... +1. Go and read up Robert's Rules of Order folks. The equivalent for your own language usually exists. Erskine May (en_GB) and Code Morin (fr_CA) off the top of my head. > 3) Once discussion on the topic has concluded, the council members > will vote on the actions requested by the developer body. Specifically note for those here that wish to dissent: "Once discussion on the topic has concluded" If the council feels there is insufficent discussion or outstanding issues, it may be postponed. GLEPs have frequently been postponed in the past. Off the top of my head, the first time it happened was GLEP44 (20060209). > That does not mean it is time for council members to concoct an > entirely new plan by the seat of their pants... which leads me to the > next topic. For some topics, alternative plans MAY be appropriate. - For GLEPs I would say that alternatives are completely out of place. The suggestion that an alternative is needed to the GLEP implies that the GLEP author(s) either need to take the further input into consideration, or convince the objecting members of the council that the objectionable portion of the GLEP is indeed sound. - For other issues, the council should certainly have the power to come up with another plan - especially if blending presented plans leads to further agreement between dissenting parties. There are certainly precedents for this: - 20051215: Manifest1 multi-hash - 20070308: Executive powers and CoC actions > 4) Council members will now be expected to ACK the agenda on the > appropriate mailing lists at least 48 hours prior to the meeting. If > you can't, let the council know. You should be able to do this without > relying on your proxy, but your proxy may do this for you as well if > you have an extended away. > 4a) Failure to ACK the agenda will be noted on the meeting minutes. The failure of a proxy to ACK should probably fall on the elected council member for whom the proxy was acting? > 4b) Council members will be expected to formulate their thoughts in > reply to the agenda items and to research the discussion they wish to > have on the mailing list PRIOR to the meeting and not fly by the seat > of their pants. > 4c) "The first I heard of this and I need 4 weeks to research this." > or any variation of the quoted statement is no longer a valid > statement. The point of the meeting is to weigh and debate the items > before us now. Do your research PRIOR to the meeting, not during. Could you codify the time requirement you expect councilmembers to put into their work? In the past, sometimes councils were busy with real-life, so independent research did not get done by any member prior to the meeting. > I look forward to the current council members ack'ing this e-mail > (whether it be in parts or in whole) and I look forward to our Gentoo > developer body ack'ing this e-mail to show support that they want a > "goal oriented action taking" council and not a "delay and talk" > council. This council has only a few short weeks remaining and now is > the time to start reviewing candidates and seeing if they will do for > you in the coming year what you expect a council to do. As developer, but also as a former council member, I'd like to ACK the general principles espoused in this email. A few of the details strike me as reactionary, but the concept is sound. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp3IKANdCrzE.pgp Description: PGP signature
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Doug Goldstein wrote: > All, > > The current council meetings have gotten completely out of hand for > weeks meetings have become nothing more then a continuation of the > senseless bicker-fest that have become the e-mail threads on GLEP54, > GLEP55, and EAPI-3 without any real progress or sense coming of them. > It's taken me a little bit to step up and put a stop to it but I fully > intend on putting a stop to it. The point of the council meetings is > to bring up a topic and decide on its merits whether it should be > brought into the Gentoo Project or not. I quote from the first line of > the Gentoo Council website: I would strongly advice that EAPI-3 and GLEP's 54/55 be dropped at least for the time being (at a minimum 90 days). The argument has left any trappings of merit or rational behind, and has replaced them with religion. As this is now a dogmatic issue a resolution cannot be reached at this time. > > We have all collectively failed the Gentoo Project since we have not > been doing this for the past several weeks. Vigorous debate fails no one. Religious zealotry however fails us all. In recognizing that this is what's happening iwth EAPI-3, and GLEP's 54/55 is the first step towards moving on to a new and fair debate on these issues down the road. Andrew
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Hello, I haven't been able to attend a council meeting for a bit since it occurs at ~2:30 am my time, but for what it's worth: On Mon, 2009-06-01 at 23:15 -0500, Doug Goldstein wrote: [...] > 1) Agenda Topics are posted to the appropriate mailing lists at a > MINIMUM 7 days prior to the meeting. (That means the agenda must be > formed by this Thursday). > 1a) Any changes to the agenda should be ACK'd by the council members > (off list via the council alias). Changes can not occur less than 48 > hours from the meeting. Subject to common-sense w.r.t. making exceptions (which I presume will be few and far-apart), ++. > 2) The #gentoo-council channel become moderated as we had discussed > several times in the past. > 2a) Topics will be brought up and people wishing to address the > council and the developer body at large should speak to the day's > appointed moderator. We can take turns or I can do it (maybe it'll > keep my head from banging against the keyboard as it has in the past > watching the various non-council members argue completely non-agenda > items back and forth). > 2b) Requests are made in tells and honored in turn. The moderator will > announce to the channel who wishes to speak and the order they are in > and will efficiently work through the list. If you can not remain on > topic, you will lose your voice. I thought the intention was to have this as the policy whenever things got out of hand. Am I wrong, or is it just that this not been enforced? I'm all for this as a discretionary measure. > 3) Once discussion on the topic has concluded, the council members > will vote on the actions requested by the developer body. That does > not mean it is time for council members to concoct an entirely new > plan by the seat of their pants... which leads me to the next topic. ++ > 4) Council members will now be expected to ACK the agenda on the > appropriate mailing lists at least 48 hours prior to the meeting. If > you can't, let the council know. You should be able to do this without > relying on your proxy, but your proxy may do this for you as well if > you have an extended away. > 4a) Failure to ACK the agenda will be noted on the meeting minutes. I don't really see this as being strictly necessary. If we find ourselves having to use this measure often, there's definitely something wrong with the system. > 4b) Council members will be expected to formulate their thoughts in > reply to the agenda items and to research the discussion they wish to > have on the mailing list PRIOR to the meeting and not fly by the seat > of their pants. ++ > 4c) "The first I heard of this and I need 4 weeks to research this." > or any variation of the quoted statement is no longer a valid > statement. The point of the meeting is to weigh and debate the items > before us now. Do your research PRIOR to the meeting, not during. I guess 4 (c) can be made - if enough members of the council require more time to grok the issue, then just postpone the item? At one of the earlier meetings that I had attended, the modus operandi was to allocate some amount of time to discussion of the topic, and then either (a) make a decision (if things are reasonably clear), (b) defer till the next meeting (if they're not) Keeping things time-bound might sound a bit overboard, but for the more contentious topics, it's a good way to make sure that you don't just end up running around in circles. -- Arun signature.asc Description: This is a digitally signed message part
[gentoo-dev] Jun 11th, 2009 Council Meeting Format
All, The current council meetings have gotten completely out of hand for weeks meetings have become nothing more then a continuation of the senseless bicker-fest that have become the e-mail threads on GLEP54, GLEP55, and EAPI-3 without any real progress or sense coming of them. It's taken me a little bit to step up and put a stop to it but I fully intend on putting a stop to it. The point of the council meetings is to bring up a topic and decide on its merits whether it should be brought into the Gentoo Project or not. I quote from the first line of the Gentoo Council website: "The elected Gentoo Council decides on global issues and policies that affect multiple projects in Gentoo." We have all collectively failed the Gentoo Project since we have not been doing this for the past several weeks. I propose the following changes be instituted before the meeting and happen through the meeting: 1) Agenda Topics are posted to the appropriate mailing lists at a MINIMUM 7 days prior to the meeting. (That means the agenda must be formed by this Thursday). 1a) Any changes to the agenda should be ACK'd by the council members (off list via the council alias). Changes can not occur less than 48 hours from the meeting. 2) The #gentoo-council channel become moderated as we had discussed several times in the past. 2a) Topics will be brought up and people wishing to address the council and the developer body at large should speak to the day's appointed moderator. We can take turns or I can do it (maybe it'll keep my head from banging against the keyboard as it has in the past watching the various non-council members argue completely non-agenda items back and forth). 2b) Requests are made in tells and honored in turn. The moderator will announce to the channel who wishes to speak and the order they are in and will efficiently work through the list. If you can not remain on topic, you will lose your voice. 3) Once discussion on the topic has concluded, the council members will vote on the actions requested by the developer body. That does not mean it is time for council members to concoct an entirely new plan by the seat of their pants... which leads me to the next topic. 4) Council members will now be expected to ACK the agenda on the appropriate mailing lists at least 48 hours prior to the meeting. If you can't, let the council know. You should be able to do this without relying on your proxy, but your proxy may do this for you as well if you have an extended away. 4a) Failure to ACK the agenda will be noted on the meeting minutes. 4b) Council members will be expected to formulate their thoughts in reply to the agenda items and to research the discussion they wish to have on the mailing list PRIOR to the meeting and not fly by the seat of their pants. 4c) "The first I heard of this and I need 4 weeks to research this." or any variation of the quoted statement is no longer a valid statement. The point of the meeting is to weigh and debate the items before us now. Do your research PRIOR to the meeting, not during. I know this is a sharp pill to swallow and a firm deviation from the past 2 or 3 months of council meetings but this is something the council toyed with before and it was successful until we started to let it slip to the situation we have today. I look forward to the current council members ack'ing this e-mail (whether it be in parts or in whole) and I look forward to our Gentoo developer body ack'ing this e-mail to show support that they want a "goal oriented action taking" council and not a "delay and talk" council. This council has only a few short weeks remaining and now is the time to start reviewing candidates and seeing if they will do for you in the coming year what you expect a council to do. If people like this, great. If people don't, then I can feel comforted that I spoke my piece about what I want to see the council become and people don't share the same vision as me. -- Doug Goldstein Gentoo Council Member
Re: [gentoo-dev] openswan compile issue with glibc-2.10
Peter Alfredsen writes: > Please attach your patch here: > https://bugs.gentoo.org/show_bug.cgi?id=271987 > > We use bugzilla for bug reports. > Done, thank you for providing the link to the existing bug report. -- Timur Aydin
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
On Tue, Jun 2, 2009 at 3:56 AM, Mounir Lamouri wrote: > This feature (ACCEPT_LICENSE) is important to remove check_license() > call from ebuilds which need user input while merging. Interaction in > ebuild should be avoided and it is a blocker for a fully functional > portage backend for packagekit (my gsoc project). > Most licenses aren't for usage, but for distribution -- surely you mean EULAs? -- ~Nirbheek Chauhan
Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
On K, 2009-05-20 at 00:55 +, Duncan wrote: > Mart Raudsepp posted > 1242777068.30374.30.ca...@localhost, excerpted below, on Wed, 20 May 2009 > 02:51:08 +0300: > > > It is about getting popular packages (based on various metrics) into the > > official tree for easy access and with known quality. > > Perhaps some concrete examples of packages you have in mind might be > useful. A big part of the thing is to get things better qualified in popularity. Encouraging users on maintainer-wanted bugs (automatically adding a link to a describing page if assignee=maintainer-wanted?) to leave their votes appropriately, automated methods to sort bugs based on comment and activity, comparing with popularity metrics in other distributions that have something like the not-really-existing yet gentoo-stats, perhaps working on gentoo-stats, etc etc. > I list in the footnote[1] a couple I originally merged from > sunrise, that are now in-tree. I that the type of package you had in > mind? What /about/ sunrise packages? Will you be working with them to > bring "popular" packages from there in-tree too? > > Of course in your case the ebuilds aren't in the tree yet, but bug > numbers for apps you believe fit the "popular" description might be > useful. "Popular packages" is a nebulous enough term on its own, that > some examples might help. These metrics should be worked out by an upcoming team then, not ignoring common sense. But perhaps a few examples then: miro songbird moovida (previously known as Elisa Media Center) paperbox shutter I see many of the ones I was able to list seem to be either complex deptree packages that no-one has been motivated enough yet to push through (so hopefully once that hard work gets done once, a dedicated maintainer is found easily), and stuff that would be cool to use once it's easily available and found, but not something people very much depend on to care that much alone for themselves, hence a team finding such packages at first could be useful. > Also, an example or two of what you might consider a borderline case, > that you might consider adding if the load on the proposed project wasn't > too high already, but would reject if it was. Feel free to add comments > or explanations on how you came to that conclusion, both for the popular > and borderline examples, as well, if you think it necessary. > > . > > [1] I still use sys-apps/moreutils. > > The other one was www-plugins/swfdec-mozilla and its dep media-libs- > swfdec, which I had some trouble with and eventually unmerged in favor of > a couple of youtube downloaders, since youtube was what I mainly used > swfdec for anyway. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Ciaran McCreesh wrote: > On Mon, 01 Jun 2009 23:01:04 +0200 > Mounir Lamouri wrote: > >>> The main show-stopper for this last time it came up was all those X >>> packages using their package name as a licence. Have you thought of >>> how to get that glaring QA issue addressed? >>> >> That's a very bad issue I never heard about before. >> >> I see no other options. >> >> If anyone has an idea or suggestion... >> > > Honestly, I suggest you find some poor sucker to do what the xorg team > should have done two years ago. It's a fair bit of work to fix all the > licences, but it's the best long term solution. Perhaps you could ask > the Council to see if they could nominate it as a special priority > project and encourage every developer to fix one package. > I agree it's the best long term solution but I've the feeling this is going to take a very long time. This feature (ACCEPT_LICENSE) is important to remove check_license() call from ebuilds which need user input while merging. Interaction in ebuild should be avoided and it is a blocker for a fully functional portage backend for packagekit (my gsoc project). Maybe cleaning licenses should be done before making this feature available/mandatory but we should avoid creating a never-ending task. Mounir
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Monday 01 of June 2009 06:25:06 Jorge Manuel B. S. Vicetto wrote: > Hello fellow developers and users. > I nominate: Betelgeuse Calchan peper darkside tanderson Cardoe signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On N, 2009-05-28 at 11:55 +0400, Peter Volkov wrote: > В Чтв, 14/05/2009 в 03:32 +0300, Mart Raudsepp пишет: > > Project maintainer-wanted > > = > > Mart, I think that it's good idea to create such project but with a > different goals. I think currently maintainer-wanted alias is missed by > most developers: new packages are assigned there and from time to time > random developer picks package he needs or user moves ebuild into > Sunrise but nobody actually cares about packages/mail going there in > general. The goal of maintainer-wanted project could be just gather > statistics and highlighting most popular/interesting packages there. > Something like "Top 10 most popular maintainer-wanted packages" monthly > e-mail could be really useful. Good idea in my opinion, but in a different way - the team could maintain such a (unordered) list with varying package count size and pick the packages to put to portage tree by them out of that list as well when the manpower allows to maintain the package in question. But having a list before actually packaging them in official tree could serve as another list where other maintainers could pick them up and package them before maintainer-wanted would, skipping the otherwise supposedly short time maintainer-wanted would be maintaining it -- packages that are maintained by maintainer-wanted would have a list to pick from as well, and the interested maintainer could find it from that one too. Above when I said "maintainer-wanted" I meant the herd/team with another more suitable name then to not confuse with bugs assigned to that alias that are still not maintained by anyone in the official tree (yes, co-operation with Sunrise and the like I'd see as important). -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On K, 2009-05-20 at 11:36 -0400, Richard Freeman wrote: > Mart Raudsepp wrote: > > > > The maintainer-wanted team owns that foo package then, which is why > > having a different mail alias than the existing one for "new package > > requests that aren't in gentoo tree yet" would be a good idea. > > > > Ok, I think I see where you're coming from. Essentially > maintainer-wanted is a group for people who want to collectively manage > ebuilds that don't otherwise fall into any particular project/herd. > Almost like a "misc" herd. > > If the packages are actually being maintained then I have no issues at > all with the proposal - in fact I'd endorse it (for what little that is > worth). However "maintainer-wanted" seems like a bit of a misnomer - > these ebuilds would in fact have a maintainer. Perhaps another name > could be used so that it is easy to distinguish between: > > 1. Packages not in the tree (bugzilla requests/etc). > 2. Packages in the tree that truly nobody is caring for. > 3. Packages in the tree that the proposed project is caring for but > would love to see adopted into another herd/project. > 4. Packages that are part of a more dedicated project/herd, or which > have attention from one or more particular developers. > > I don't question the value in having group #3 which I think is what > you're proposing. But, perhaps it should have a specific name/alias so > that we can tell that a package belongs to it. Your proposed team could > scour #1/2 for new builds, and bump builds in #3 back to #2 if > necessary. Treecleaners would prune #2 and ignore #3. Of course, > cooperation with Sunrise would also be a plus. Yes, that's all pretty much what I have in mind here. I have also acknowledge in various e-mails that we need a better naming for the "herd" name (not necessarily for the team) to distinguish bugzilla bugs that are maintained by this proposed team and new package request bugs that are still waiting for someone to pick them up. Also I hope the flow from #3 to #2 doesn't end up happening often and that the team would be caring about the packages in acceptable quality until it can flow to under #4. So some (in)formal policies amongst the team members to ensure the team doesn't get overwhelmed would seem appropriate. I hope the person I found to lead this project (if in the lack of others willing to do that when it becomes an actual project) clarifies things in the project proposal draft that opened this thread, which could then in the end be mostly re-used as the project page text on gentoo.org -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] openswan compile issue with glibc-2.10
On Mon, 01 Jun 2009 23:10:47 +0300 Timur Aydin wrote: > Today I have tried to merge openswan-2.4-14 into my ~x86 system. The > compilation failed because of a name clash: Please attach your patch here: https://bugs.gentoo.org/show_bug.cgi?id=271987 We use bugzilla for bug reports. /loki_val
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
Tiziano Müller said: > The people I'd like to nominate: > - halcy0n ... even though he had to resign early I hope he finds time > again to run for council, I really enjoy working together with him and I > appreciate his common sense Thanks Tiziano, but I like the extra time I'm having to work on other things right now, so I have to decline. Maybe the next time around. Thanks, -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com pgpZqzOCwvr1q.pgp Description: PGP signature
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
On Mon, 01 Jun 2009 23:01:04 +0200 Mounir Lamouri wrote: > > The main show-stopper for this last time it came up was all those X > > packages using their package name as a licence. Have you thought of > > how to get that glaring QA issue addressed? > > That's a very bad issue I never heard about before. > > I see no other options. > > If anyone has an idea or suggestion... Honestly, I suggest you find some poor sucker to do what the xorg team should have done two years ago. It's a fair bit of work to fix all the licences, but it's the best long term solution. Perhaps you could ask the Council to see if they could nominate it as a special priority project and encourage every developer to fix one package. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Mon, 01 Jun 2009 22:29:25 +0200 Tiziano Müller wrote: > The people I'd like to nominate: > > - dertobi123 ... for his solid comments, experience, common sense, > reliability > - halcy0n ... even though he had to resign early I hope he finds time > again to run for council, I really enjoy working together with him and I > appreciate his common sense > - betelgeuse ... technically skilled and experienced > - fmccor ... not sure whether possible or not since member of the > trustees. But his latest comments showed experience in organizational > tasks and that's what we need. > Thank you very much for the nomination. But as you guessed, as a trustee I am not allowed to serve on council (our bylaws prohibit it). Thus, if I ran and somehow were elected, I'd have to decline or resign as a trustee. Thus I must decline the nomination, although again I appreciate the confidence you show in me. > Probably some more later on... > > > > > -- > Tiziano Müller > Gentoo Linux Developer, Council Member > Areas of responsibility: > Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor > E-Mail : dev-z...@gentoo.org > GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Ciaran McCreesh wrote: > On Fri, 29 May 2009 19:17:03 +0200 > Mounir Lamouri wrote: > >> Most of GLEP 23 features have already been implemented in portage. >> Some since >> a long time (at least in stable portage) like multiple licenses and >> conditional >> licenses. License group and ACCEPT_LICENSE is already implemented in >> portage 2.2 (masked). >> > > The main show-stopper for this last time it came up was all those X > packages using their package name as a licence. Have you thought of how > to get that glaring QA issue addressed? > That's a very bad issue I never heard about before. I would say there is the easy workaround: we fix ACCEPT_LICENSE="* -...@eula" and this issue will never pop with a "default" configuration. But I don't like it because anyone setting ACCEPT_LICENSE to anything will stuck in in. So, why not creating a Generic-Free-License that could be set for packages with no clear/clean license but still free. The con of this solution is we will surely lost some information because we can set LICENSE="Generic-Free-License" or LICENSE="|| ( Generic-Free-License MyCreepyLicense )" because we need to have at least LICENSE="Generic-Free-License". I see no other options. If anyone has an idea or suggestion... Mounir
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
Am Montag, den 01.06.2009, 12:17 +0200 schrieb Tobias Scherbaum: > And here we go, these are the ones I'd like to nominate: > > * dev-zero, well because ... i'd like him to be on the council again! And I accept the nomination, thank you. -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] Gentoo Council Reminder for May 28
Am Mittwoch, den 27.05.2009, 20:55 +0100 schrieb Roy Bamford: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2009.05.27 13:46, Ferris McCormick wrote: > > On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote: > > > This is your friendly reminder! Same bat time (typically the 2nd & > > 4th > > > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo- > > council > > @ > > > irc.freenode.net) ! > > > > > > If you have something you'd wish for us to chat about, maybe even > > vote > > > on, let us know! Simply reply to this e-mail for the whole Gentoo > > dev > > > list to see. > > > > > > For more info on the Gentoo Council, feel free to browse our > > homepage: > > > http://www.gentoo.org/proj/en/council/ > > > > > > > > > Following is the preliminary meeting agenda. First we'll have to > > fill > > > the empty spot. After a short upgrade on EAPI-3 implementation we > > will > > > discuss the removal of old eclasses, followed by our old friend > > GLEP > > 55. > > > If we still have time we can dive into the topic of general EAPI > > > development. > > > > > > > Because Piotr recently amended GLEP55 to provide some further > > clarification and justification as well as to present a few > > alternatives > > addressing some objections people have expressed, it seems to me that > > the GLEP55 discussion should now go something like this: > > > > 1. Approve the concept in principle (I think Piotr's examples > > sufficiently show the need for something along the lines set out in > > the > > revised GLEP); > > > [snip] > > > Cheers, > > > Tiziano > > Regards, > > Ferris > > -- > > Ferris McCormick (P44646, MI) > > Developer, Gentoo Linux (Sparc, Userrel, Trustees) > > > GLEP 55 still confuses the problem and the solution. > Adding metadata to the filename is not required and is bad system > design practice. Its also the first step on the slippery slope to > adding more metadata in the future. Ok, while thinking even more about it I have to disagree. I agree with you that users should be mostly unaware of EAPI as such. But I don't see ebuilds or ebuild-names as kind of a user-visible interface the average user has to handle (even though most if not all Gentoo users will edit or even write an ebuild at least once). Instead he should use the package manager which hides those implementation details. As such I don't see a problem of exporting metadata information into the ebuild-name. -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] A different approach to reaching (more) agreement on glep 55
Hi, A lot of what I've seen in these past few months is a lot of bickering and disagreement over glep 55. I don't think that has to be. A glep shouldn't be political but should evolve as people bring up points to change and refine it. I haven't seen that been happening, so I'd like to guide the discussion in a more positive direction. So, if you could email the list with specific things you'd like to see refined or things that do not make sense to you. Basically, a list of things to be clarified. Luca presented some in the last council meeting regarding the Problem section, but I'd like to open this up to the whole glep. As always, "Patches welcome". Please note, this thread should not turn into a long discussion, and no subthread should contain >3 messages, so if you see that while writing a mail, please don't send your undoubtedly unconstructive comment(or it'll be impossible to wade through the thread looking for constructive stuff which is the point of the thread). Regards, Thomas -- - Thomas Anderson Gentoo Developer / Areas of responsibility: AMD64, Secretary to the Gentoo Council - pgpaPTDlYSqvw.pgp Description: PGP signature
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
On Fri, 29 May 2009 19:17:03 +0200 Mounir Lamouri wrote: > Most of GLEP 23 features have already been implemented in portage. > Some since > a long time (at least in stable portage) like multiple licenses and > conditional > licenses. License group and ACCEPT_LICENSE is already implemented in > portage 2.2 (masked). The main show-stopper for this last time it came up was all those X packages using their package name as a licence. Have you thought of how to get that glaring QA issue addressed? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
The people I'd like to nominate: - dertobi123 ... for his solid comments, experience, common sense, reliability - halcy0n ... even though he had to resign early I hope he finds time again to run for council, I really enjoy working together with him and I appreciate his common sense - betelgeuse ... technically skilled and experienced - fmccor ... not sure whether possible or not since member of the trustees. But his latest comments showed experience in organizational tasks and that's what we need. Probably some more later on... Am Montag, den 01.06.2009, 04:25 + schrieb Jorge Manuel B. S. Vicetto: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello fellow developers and users. > > Nominations for the Gentoo Council 2009/2010 are now open for the next > two weeks (until 23:59 UTC, 14/06/2009). > > All nominations must be sent to the gentoo-dev mailing list. If you > were nominated and want to run, you have to accept your nomination on > the same mailing list. > > Here are the rules: > > * Council elections generally happen once a year > * The council is composed of seven elected members > * Nominations are allowed from June 1st 00H00 UTC to June 14th 23H59 UTC > * Only Gentoo developers may be nominated > * Anyone can nominate (nominating yourself is OK) > * Nominees must accept their nomination before voting begins > * Voting is opened from June 16th 00H00 UTC to June 30th 23H59 UTC > (there is one day of break between nominations and voting so the > infra team has time to set up everything) > * Only Gentoo developers may vote > * Gentoo uses the Condorcet method of voting > > The page listing all nominations is here: > http://www.gentoo.org/proj/en/elections/council-200906-nominees.xml > > If you don't know what the Gentoo Council is, you can read about it here: > http://www.gentoo.org/proj/en/council/ > > If you want to ask a question or share your thoughts, contact any of > the election officials: > > Jorge Manuel B. S. Vicetto (jmbsvicetto) > Łukasz Damentko (rane) > Roy Bamford (neddyseagoon) > Shyam Mani (fox2mike) will be doing infra magic. > > You can send us an e-mail (gentoo-elections at gentoo dot org) or find > us on Freenode (#gentoo-elections, #gentoo-dev, so on). > > For the elections team, > > - -- > Regards, > > Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org > Gentoo- forums / Userrel / Devrel / SPARC / KDE > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkojWCIACgkQcAWygvVEyAKcBQCgi7CbK2zTX8y/FqDvTUfsN2l4 > ig4AoI6cI1m8dlTXRKtfYyTUfGBMvhZC > =72eQ > -END PGP SIGNATURE- -- Tiziano Müller Gentoo Linux Developer, Council Member Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] openswan compile issue with glibc-2.10
On Monday 01 of June 2009 22:10:47 Timur Aydin wrote: > Today I have tried to merge openswan-2.4-14 into my ~x86 system. The > compilation failed because of a name clash: > Hi Timur. Mind to report this issue on bugs.gentoo.org with patch attached there? Also don't forget to check if the bug wasn't reported before! -- Cheers Dawid Węgliński
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Mike Frysinger wrote: > This is your monthly friendly reminder ! Same bat time (typically > the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel > (#gentoo-council @ irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even > vote on, let us know ! Simply reply to this e-mail for the whole > Gentoo dev list to see. > > Keep in mind that every GLEP *re*submission to the council for review > must first be sent to the gentoo-dev mailing list 7 days (minimum) > before being submitted as an agenda item which itself occurs 7 days > before the meeting. Simply put, the gentoo-dev mailing list must be > notified at least 14 days before the meeting itself. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ > Hi, I would like to get ACCEPT_LICENSE default value [1] discussed in the next Council. If I can even get it widely discussed in gentoo-dev before the council, a vote will be great. But it looks like it is not interesting so much people out there. [1] http://archives.gentoo.org/gentoo-dev/msg_d5c1e7285399ebc27a74bdd02cb4d037.xml Mounir
[gentoo-dev] openswan compile issue with glibc-2.10
Today I have tried to merge openswan-2.4-14 into my ~x86 system. The
compilation failed because of a name clash:
cc -I. -I/home/ta/tmp/openswan-2.4.14.orig/linux/net/ipsec
-I/home/ta/tmp/openswan-2.4.14.orig/linux/include
-I/home/ta/tmp/openswan-2.4.14.orig -DDEBUG -DWITH_UDPFROMTO
-DHAVE_IP_PKTINFO -I/home/ta/tmp/openswan-2.4.14.orig/include -g -O3
-DDISABLE_UDP_CHECKSUM -Wall -Wpointer-arith -Wcast-qual
-Wstrict-prototypes -Wbad-function-cast -DNAT_TRAVERSAL -c -o
optionsfrom.o optionsfrom.c
optionsfrom.c:34: error: conflicting types for 'getline'
/usr/include/stdio.h:651: error: previous declaration of 'getline' was here
make[2]: *** [optionsfrom.o] Error 1
make[2]: Leaving directory
`/home/ta/tmp/openswan-2.4.14.orig/lib/libopenswan'
make[1]: *** [programs] Error 1
make[1]: Leaving directory `/home/ta/tmp/openswan-2.4.14.orig/lib'
make: *** [programs] Error 1
The getline function is implemented in the optionsfrom.c source file in
the openswan distribution. But the same function is implemented in glibc
as well, but has a different signature and return code. It seems it is
best to rename the getline function to something else to resolve this.
Attached is a patch that renames all insances of getline to osw_getline.
--
Timur
diff -Nru openswan-2.4.14.orig/lib/libopenswan/optionsfrom.c
openswan-2.4.14/lib/libopenswan/optionsfrom.c
--- openswan-2.4.14.orig/lib/libopenswan/optionsfrom.c 2004-04-09
21:00:38.0 +0300
+++ openswan-2.4.14/lib/libopenswan/optionsfrom.c 2009-06-01
22:21:56.0 +0300
@@ -31,7 +31,7 @@
static const char *dowork(const char *, int *, char ***, int);
static const char *getanarg(FILE *, struct work *, char **);
-static char *getline(FILE *, char *, size_t);
+static char *osw_getline(FILE *, char *, size_t);
/*
- optionsfrom - add some options, taken from a file, to argc/argv
@@ -149,7 +149,7 @@
char *endp;
while (w->pending == NULL) {/* no pending line */
- if ((w->line = getline(f, w->buf, sizeof(w->buf))) == NULL)
+ if ((w->line = osw_getline(f, w->buf, sizeof(w->buf))) == NULL)
return "error in line read";/* caller checks EOF */
if (w->line[0] != '#' &&
*(w->line + strspn(w->line, " \t")) != '\0')
@@ -171,7 +171,7 @@
if (*linep == NULL)
return "out of memory for new line";
strcpy(*linep, p);
- } else /* getline already malloced it */
+ } else /* osw_getline already malloced it */
*linep = p;
return NULL;
}
@@ -203,10 +203,10 @@
}
/*
- - getline - read a line from the file, trim newline off
+ - osw_getline - read a line from the file, trim newline off
*/
static char * /* pointer to line, NULL for eof/error */
-getline(f, buf, bufsize)
+osw_getline(f, buf, bufsize)
FILE *f;
char *buf; /* buffer to use, if convenient */
size_t bufsize;/* size of buf */
[gentoo-dev] Last rites: dev-java/adaptx
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Serkan Kaba (01 Jun 2009) # Last-rited Bug #272117 # Hard depends on Java 1.4 (Bug #118291) dev-java/adaptx - -- Sincerely, Serkan KABA Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkokEXQACgkQRh6X64ivZaLe7QCfSBWecTEV5FolqQlwkCrUzIni P1YAnRP7HdzEHPtAICAW7P8ICunc4VIj =hG19 -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
Thank you, Patrick and Tobias. I accept the nomination. Ulrich
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
Nirbheek Chauhan wrote: > Hello, > > On Mon, Jun 1, 2009 at 9:55 AM, Jorge Manuel B. S. Vicetto > wrote: >> Nominations for the Gentoo Council 2009/2010 are now open for the next >> two weeks (until 23:59 UTC, 14/06/2009). >> > > I would like to kick-start the nominations by nominating Mart Raudsepp > (leio), Petteri Räty (betelgeuse), and Luca Barbato (lu_zero) [all of > them are CCed] > Another year of following overly long GLEP threads, who would refuse? Any way consider me as running again. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
I knew I wasn't done. I also nominate: arfrever calchan -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
On Mon, Jun 1, 2009 at 8:56 PM, Markos Chandras wrote: > I really dont like the idea of changing the file extension in anyway since > .ebuild is something that defines Gentoo. It is like changing .deb for Debian > :P. Somethings must stay untouched. ++ Sentimental value ftw! /me wears asbestos underwear in preparation of meta-flame-fest over this -- ~Nirbheek Chauhan
Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
> Hello people, > > as the discussion about glep55 has gone in circles long enough I decided to > collect the various ideas presented around that theme complex and compare > them in a way that might allow us to reach a sane decision. > > Since it has become quite a lot of text I've kept some parts in sentence > fragments and bullet points. If anyone feels the need to change that into > more verbose wording feel free to do so, I hope the idea is clear enough. I > feel it is still a draft and could use some massaging. > > If I should have forgotten any approach or misrepresented one I'd > appreciate an updated or rephrased section so it can be easily updated. > > For anyone not interested in reading the whole thing, the conclusion is > that we want to have the eapi in an easily parsed form in the ebuilds. The > versioning rule change discussion (mostly glep54) should happen in an > independent discussion. > > hth, > > Patrick Thanks for that :) I am so on board with nihilists' proposal but if this is not accepted, haubis' seems the most clean solution to me. I really dont like the idea of changing the file extension in anyway since .ebuild is something that defines Gentoo. It is like changing .deb for Debian :P. Somethings must stay untouched. -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sunrise/Sound] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Gentoo Council 2009/2010 - Nominations are now open
* Patrick Lauer : > People I nominate: > > * tove, because he has done an awesome job keeping perl alive and has shown > consistent sane opinions in technical discussions Thanks, but I have to decline. pgpCDmFKgCMJ9.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Patrick Lauer wrote: > People I nominate: > * zmedico, because he has managed to beat portage into a really good shape and > keeps adding features that make users happy Thanks, but no thanks. I'm busy with other stuff. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoj7xMACgkQ/ejvha5XGaOLhQCfZsD4V5Zk1seGhPpb8sspE6tX 73kAoLOFCmN8hwH10h5XtXIM3nN0ABYM =Ivl+ -END PGP SIGNATURE-
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
On Mon, Jun 1, 2009 at 6:14 AM, Wernfried Haas wrote: > I'd like to counter-nominate you Aww... That must hurt. Denis.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
2009-06-01 07:30:01 Mike Frysinger napisał(a):
> This is your monthly friendly reminder ! Same bat time (typically
> the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel
> (#gentoo-council @ irc.freenode.net) !
>
> If you have something you'd wish for us to chat about, maybe even
> vote on, let us know ! Simply reply to this e-mail for the whole
> Gentoo dev list to see.
Please vote on:
* Temporary unlocking of list of features of EAPI="3"
* Allowing bash-4.0 features in EAPI="3" ebuilds
* Temporary disallowing of adding bash-4.0 features to ebuilds in
gentoo-x86 repository until ${TIME:-1 month} has passed since
stabilization of =app-shells/bash-4.0* on all architectures.
Details of this proposition were already discussed on:
http://archives.gentoo.org/gentoo-dev/msg_fac31baaca8de3fb39ba6209fced9362.xml
--
Arfrever Frehtes Taifersar Arahesis
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
I agree with patrick nominees expect one addition. I add patrick himself to prove us that he can not only do benchmarks but to force us to do them :D signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Last rites: media-video/mplayer-bin
# Samuli Suominen (3 Aug 2008) # Unmaintained. Masked for removal wrt #233394. # Open security bugs #208566, #215006 and #231836. media-video/mplayer-bin Steve
[gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
I nominate: ssuominen armin76 Perhaps others later. Regards, Ferris -- Ferris McCormick (P44646, MI) Developer, Gentoo Linux (Sparc, Userrel, Trustees) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
I'd like to counter-nominate you since you do a really good job. :-P cheers, Wernfried -- Wernfried Haas (amne) - amne (at) gentoo.org Gentoo Forums - http://forums.gentoo.org forum-mods (at) gentoo.org #gentoo-forums (freenode) pgp2DpnRWtMmS.pgp Description: PGP signature
Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
> glep55: See GLEP55. To summarize: The eapi is put into the file name so > that the package manager knows the EAPI (and thus how to handle this > file format). While it simplifies the eapi discovery this comes at a > high price as there is no reliable way to find and validate all ebuilds. i must have missed the last point in the previous discussions. could someone perhaps point me to a post explaining the "high price" part? or just repeat it here thanks kind regards Thilo
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
And here we go, these are the ones I'd like to nominate: * dev-zero, well because ... i'd like him to be on the council again! * ulm because I think he's an excellent addition to the council * amne, because I want him to stop slacking :P that's it for now :) wkr, Tobias Am Montag, den 01.06.2009, 10:48 +0200 schrieb Patrick Lauer: > People I nominate: > > * leio / mraudsepp, because he's done a really good job protecting the > distro's interests > > * Cardoe, because he is working goal-oriented and doesn't care about the > wargharbling and instead goes for restults > > * lu_zero, because he's done a good job and brings in his own ideas without > going religious on people with different opinions > > * dertobi123, because he's done a good job and keeps organizing the Gentoo > presence on german open source events > > * ulm, because he's a good fellow that deserves to show what he can do on the > council after being pulled in for the rest of the term to replace dberkholz > > * solar, because he knows how things work behind the scenes (infra, portage) > and doesn't tolerate infinite discussions > > * grobian, because he's shown leadership and dedication with Prefix and the > other things he got involved with > > * quantumsummers, because he has shown dedication and reliability > > * scarabeus, because he knows what he wants and promised to beat me up if I > didn't nominate him > > * tove, because he has done an awesome job keeping perl alive and has shown > consistent sane opinions in technical discussions > > * zmedico, because he has managed to beat portage into a really good shape and > keeps adding features that make users happy > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[gentoo-dev] Monthly Gentoo Council Reminder for June
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every GLEP *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/
Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open
People I nominate: * leio / mraudsepp, because he's done a really good job protecting the distro's interests * Cardoe, because he is working goal-oriented and doesn't care about the wargharbling and instead goes for restults * lu_zero, because he's done a good job and brings in his own ideas without going religious on people with different opinions * dertobi123, because he's done a good job and keeps organizing the Gentoo presence on german open source events * ulm, because he's a good fellow that deserves to show what he can do on the council after being pulled in for the rest of the term to replace dberkholz * solar, because he knows how things work behind the scenes (infra, portage) and doesn't tolerate infinite discussions * grobian, because he's shown leadership and dedication with Prefix and the other things he got involved with * quantumsummers, because he has shown dedication and reliability * scarabeus, because he knows what he wants and promised to beat me up if I didn't nominate him * tove, because he has done an awesome job keeping perl alive and has shown consistent sane opinions in technical discussions * zmedico, because he has managed to beat portage into a really good shape and keeps adding features that make users happy
