Re: [gentoo-dev] New developers / polish invasion :)
On Thu, Sep 15, 2005 at 01:52:41AM +0200, [EMAIL PROTECTED] wrote: Please give them a warm welcome :) Ok, here's a warm welcome to nelchael and mkay. Would you like fries with it? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
Nathan L. Adams wrote: What about giving QA temporary revoke powers just like infra (Curtis Napier's idea), traditionalist? Fixing devrel's resolutions policies and Curtis' idea don't have to be mutually-exclusive. The idea behind -infra temporary revoke power is to react to emergency situations (as in we must do something *now*). Not sure a repeated QA violation would fall into that emergency category. The solution is rather to have a devrel liaison inside the QA team (or the other way around). These are not closed groups. We do essentially the same with infrastructure and security, we have liaisons and people that are members of both groups, rather than saying security should have wheel to do security audits and emergency security fixes. Works a lot better that way. -- Koon -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
On Thu, Sep 15, 2005 at 09:42:19AM +0200, Thierry Carrez wrote: Nathan L. Adams wrote: What about giving QA temporary revoke powers just like infra (Curtis Napier's idea), traditionalist? Fixing devrel's resolutions policies and Curtis' idea don't have to be mutually-exclusive. The idea behind -infra temporary revoke power is to react to emergency situations (as in we must do something *now*). Not sure a repeated QA violation would fall into that emergency category. The solution is rather to have a devrel liaison inside the QA team (or the other way around). These are not closed groups. Agreed. We don't need a second devrel, rather we need to make sure QA isn't ignored by devrel -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developers / polish invasion :)
On Thursday 15 September 2005 01:52, [EMAIL PROTECTED] wrote: We have two new developers from Poland. It's creepy... we have also a polish invasion in #gentoo-bsd ... Well... welcome nelchael and mkay... hope you won't find too many [EMAIL PROTECTED] bugs laying around :P -- Diego Flameeyes Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpk0i1vgclkk.pgp Description: PGP signature
[gentoo-dev] first council meeting
The first council meeting happened today at 1900UTC. All council members attended. 1. Official confirmation that the council is inline with the already-defined roles of devrel and QA and its commitment to make already-approved GLEPs (including GLEP 31) respected (Clarification of position asked by many people including Ciaran McCreesh, Patrick Lauer and Lance Albertson) Confirmed with the caveat that the council is not taking on disciplinary responsibilities. The QA team should take complaints regarding unresolved technical violations to devrel to pursue displinary action. Regarding GLEP 31, the council is in favor of enforcement ASAP, provided nano is confirmed to be capable of compliance. That will set the bar to require UTF-8 capable editors for portage work. (note: agenda reordered per request) 3. glep40: Standardizing arch keywording across all archs Vote asked by Grant Goodyear Approved. 2. glep33: Eclass Restructure/Redesign Vote asked by Brian Harring Approved. 4. Discussion of the next meeting date(s) 2nd Thursday of each month, 1900UTC. Rain date of 3rd Thursday. 5. Open QA session Full meeting log available at http://gentoo.org/proj/en/council/meeting-logs/20050915.txt Please post follow-ups to gentoo-council ML (subscription required) Regards, Aron -- Aron Griffis Gentoo Linux Developer pgpFWsVRuq3Fp.pgp Description: PGP signature
Re: [gentoo-dev] first council meeting
On Thu, 2005-15-09 at 16:51 -0400, Aron Griffis wrote: 3. glep40: Standardizing arch keywording across all archs Vote asked by Grant Goodyear Approved. What does that glep mean anyways ? Appart from the creation of the x86 team, is there any action to be taken? - Is the maint keyword approved? - Does it mean that devs who are not part of the x86 team can't move packages from ~x86 to x86 ? - Is there something else I failed to read? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer x86 Security Liaison -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Thursday 15 September 2005 05:57 pm, Chris Gianelloni wrote: On Thu, 2005-09-15 at 17:25 -0400, Olivier Crete wrote: - Does it mean that devs who are not part of the x86 team can't move packages from ~x86 to x86 ? Correct. They can, however, make previous arrangements with the x86 arch team to allow them to stabilize their own packages. What this says is I acknowledge that anything that I break or that breaks on x86 with my package, I get to fix and is not the responsibility of the x86 arch team. The x86 team will keep a list of these developers. This is similar (or identical) to how other arch teams work. For example, I'm not a member of the amd64 arch team, but they know I have an amd64 and use it as my primary development box, so I have made arrangements with them so I can ~amd64 - amd64 my own packages. If something breaks, I pick up the pieces, not them. actually this is came up in the meeting as something we would like to see spelled out explicitly ... either as a GLEP itself or as a policy update to current stabilization practices the GLEP was approved on the grounds that we need an x86 team and that it needs to be treated as any other arch ... arch team interaction with maintainers should be spelled out clearly rather than part of a single sentence '... or make individual arrangements with the x86 arch team.' -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
Greetings, On behalf of the g/fbsd and macos teams, I'd like to call a meeting for all members of the gentoo-alt projects (and anyone else who would like to attend) on Monday September 26 at 19:00 UTC. Items on the Agenda so far: * Naming and categorization of alt-arch system packages * Merging patches in the main tree * Additional Repoman checks (cp -[a,d], /bin/false, etc.) * Project page content (tech notes, tasks data, active devs, etc) * Portage rewrite - alternate prefix installs(!), moving/adding platform dependent code to loadable modules * Alt-project roadmap Flame-on. --Kito -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Friday 16 September 2005 05:51, Aron Griffis wrote: Regarding GLEP 31, the council is in favor of enforcement ASAP, provided nano is confirmed to be capable of compliance. That will set the bar to require UTF-8 capable editors for portage work. Confirmed. -- Jason Stubbs pgpeTCg9uOJs8.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kito wrote: Greetings, On behalf of the g/fbsd and macos teams, I'd like to call a meeting for all members of the gentoo-alt projects (and anyone else who would like to attend) on Monday September 26 at 19:00 UTC. Items on the Agenda so far: * Naming and categorization of alt-arch system packages * Merging patches in the main tree * Additional Repoman checks (cp -[a,d], /bin/false, etc.) * Project page content (tech notes, tasks data, active devs, etc) * Portage rewrite - alternate prefix installs(!), moving/adding platform dependent code to loadable modules * Alt-project roadmap I'm writing a tool, called esyntaxer, that finds certain common ebuild errors and automagically corrects them if possible. Yes, I'm aware of the overlaps with repoman, and no this isn't a duplication of work. Anyhow, I would be very keen on any ideas you may have for checks that can be added to esyntaxer that would make ebuilds more agreeable on 'alternate' platforms. Any suggestions, feedback, etc are greatly appreciated. Thanks, Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDKgoo2QTTR4CNEQARAtqxAJ0VFFq6m7vn0Z1VF88pUHZqc4SkzgCeIyxG uralm8EaACd5FLYiMxo5Tr4= =1oix -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Clarification of packages cd's for 2005.1
I am looking at building a box this weekend. I want to use 2005.1 and if possible the packages cd (for a quick result) . I have an athlon 1133. I am re-building it after a root account compromise (don't ask or I'll cry). According to the release announcement the package cd's don't seem to have an athlon version any more. http://www.gentoo.org/news/20050808-annoncement-release-2005.1.xml (the choices seem to be alpha amd64 ppc (32 bit) ppc (64 bit) sparc64 x86). However on http://tracker.netdomination.org/ there are package cd's for a whole lot of other sub-arches - i686, athlon-xp, P3, P4 and more. Are these official gentoo - if not can anyone tell me about their origin and reliability? Also is athlon-xp compatible with athlon? Or should I go for i686? Actually using i686 could be a bonus as it would mean I could share binaries between my desktop and my p3 laptop, which is compiled for 686. -- Nick Rout [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo alt-projects meeting 9/26 1900 UTC
I guess knowing where the meeting will be held might help attendance a little... #gentoo-alt it is! --Kito -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] Idea: new flags for ebuilds
Hi, Mainly, what came in my mind is to do something like: !! [ U ] media-video/ati-drivers The change is !!, what is saying the user that he/she must be looking at the output like ( at the end of the emerge ): * * Now the libs are on /usr/libs * (or whatever). If the notification is information, the !! could be green, but if they are warning about something, they could be red, and everything could be defined on the package's ebuilds. Bye.
[gentoo-portage-dev] Idea: new flags for ebuilds
Hi,Mainly, what came in my mind is to do something like:!! [ U ] media-video/ati-driversThe change is !!, what is saying the user that he/she must be looking at the output like ( at the end of the emerge ): ** Now the libs are on /usr/libs*(or whatever).If the notification is information, the !! could be green, but if they are warning about something, they could be red, and everything could be defined on the package's ebuilds. So before updating, emerge -vuDp world, we could write down or save into a file which updates' logs should we read later, and which aren't so important to read, saving time not reading all of them. Bye.-- Saludos,Rafael Fernández López.A la vista de suficientes ojos todos los errores resultan evidentes - Linus Torvalds
