Re: [gentoo-dev] New developer: Pierre-Yves Rofes (p-y)
> Please give him the usual flamy welcome. /me hugs Pierre-Yves -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Friday 13 July 2007 01:17, Marius Mauch wrote: > On Thu, 12 Jul 2007 15:43:59 -0700 > > "Chrissy Fullam" <[EMAIL PROTECTED]> wrote: > > An additional method discussed was to have all non-dev emails on > > a timeout, pick a number of hours, and then the email if not > > moderated would be released. (non-dev sends his email, time period > > expires and no one booted it, so the email rolls through) > > For what it's worth, _IF_ this proposal goes through I'd strongly prefer > that mode of operation, so that moderation can't become a limiting > factor. > > Marius > > PS: Am I the only one who missed both reminders for the meeting? No, I missed them and the meeting as well:-( Before I recently joined the council I was against implementing the Proctors but now that we they apparently have been disbanded I think we're better off with an open -dev than some form of moderation. Flamefest contributors should be temporarily blacklisted. We can have a -dev-announce or -dev-info for devs that don't want to wade through all the mails here on -dev. We still need -core for private communications and need input on -dev from non-devs. As a very busy person I wouldn't want the extra burden of moderating emails to -dev. /me smacks himself for missing the meeting -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Friday 13 July 2007 03:41, Daniel Ostrow wrote: > On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: Works for me. -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
On Monday 02 July 2007 21:10, Torsten Veller wrote: > Let me nominate the current council members: > > Sune Kloppenborg Jeppesen jaervosz YES. When I start on my new job I'll be a lot more online. I'll write some more before election time. But already now I can say that I will work for keeping Gentoo as open as possible, I don't think permanent moderation or any form of censorship will really do us any good. -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
William L. Thomson Jr. wrote: > Fact is -dev's volume is getting to the point where it's productivity is > diminishing. Both with dev <-> dev and dev <-> world. The entire idea > here is to help correct that and makes things BETTER :) I hear you. (Although I disagree that there is a relationship between SNR and dev <-> dev and dev <-> world.) And you're right that this is something that is a result of the organisation growing. And so the question we must face is _how_ do we want it to grow. At the moment gentoo-dev is a "one big noisy room" forum. This is seen as a "problem" Propose solutions have included: 1) The "Let's divide up the room" solution - (and so we have proposals for gentoo-politics, gentoo-flamewar and other more "specialised" fora) 2) The "Let's reduce the people in the room" solution (which is what the OP's porposal is in essence) The first doesn't work because it's well nigh impossible to enforce what is on or off topic. The second "solution" begs the question of "who do we let in the room?" I submit to you that demarcating based on dev status is a Bad Idea. Some devs make the room less productive, some non-devs would make the room more productive. Unfortunately, demarcation of insiders and outsiders by any other means would be arbitrary. We arrive at the the third "solution" 3) People in the room can choose to take part in some conversations and ignore others as they see fit. This is basically the first two solutions implemented personally rather than globally. It's easily implemented through filters and sheer common sense. Oh, and it's also the status quo. W. PS. My heart rate and the alarm bells of being close to repeating myself indicate that I'm close to being fuel for flame here. Please excuse if I don't continue to post. Not being rude, just exercising some of that common sense. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] laying out arch profiles
Chris Gianelloni wrote: On Thu, 2007-07-05 at 18:47 -0400, Mike Frysinger wrote: you proposing we rearchitect it all or just for testing purposes before going live ? i can see both ... I am proposing rethinking all of it. My current thoughts run something like this: arch/amd64 arch/ppc (not ppc/ppc64 or ppc/ppc32) base default/linux default/freebsd default/macos kernel/darwin kernel/linux kernel/freebsd release/2007.1 target/desktop target/server userland (these aren't all the same type of thing) userland/32-bit userland/64-bit userland/multilib userland/freebsd userland/hardened userland/linux (this could be glibc, instead) userland/macos userland/no-nptl (not sure we really need this, at all) userland/nptl (this either) userland/selinux userland/uclibc Of course, this is just my rough outline. What you would end up with, as a profile, is something like this: default/linux/amd64/2007.1/desktop (not much different from now) I kinda thought up a system like this long ago, but it was more in line with node-based profiles. And wou;d've required gutting the current profile code in portage entirely. The idea being that, you construct the profile up in nodes from the top level (much like one does their PATH variable), and the profiles would be re-arranged into things like arch/, libc/, kernel/, etc.. In a way, I re-organized mips' 2007.1-dev profiles to quasi reflect how we'd look in such a layout. But I like this idea -- it goes halfway towards nodes to some extent (at least lines things up for nodes or some other implementation that maybe treats parents better). antarus even had a small draft document up on it that's better in detail: http://dev.gentoo.org/~antarus/essays/mixin-profiles.txt (later on, it was decided that there would have to be a pre-defined order for the first four nodes: base:arch:kernel:userland, and these first four nodes could not repeat. Everything thereon after was swappable and allowed to be placed in any order, such as base:mips:linux:glibc:ip30:o32 (where o32/ip30 can be swapped around)) But I definitely see this as a 2008.0 thing at the earliest. I also see no problem with mips joining in on the fun to play with things either! --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New developer: Pierre-Yves Rofes (p-y)
On Sat, July 14, 2007 8:30 pm, Petteri Räty wrote: > It's a joint pleasure for me and diox to introduce to you Pierre-Yves "py" Rofes. Instead of the snake people he will be joining our security team. Py originates from Paris, France, and has just finished his studies in computer science. He'll be hired soon (or maybe already was?) as a security network engineer for a small consulting company. Yep, I just finished my internship and signed last week actually. > As for the usual personal side of things this is how he describes his hobbies: "Except from gentoo, I like sport, especially rowing and handball (I won the national rowing championship in 2001 when I was in high school in 2001)." Yeah, and that was in 2001 if you still didn't got it :D Damn, I'd better read emails a second time before sending... > > Please give him the usual flamy welcome. > Thanks. I think some of you already know me, especially inside the arches teams :) While I'm here, I'd like to thank the whole security team for their welcome, and especially Falco who mentored me (he's on vacation atm and will probably never read this when catching up 2 weeks of mails, but whatever). @Santiago / Sune / Christian: Thanks for your welcome. @Remi: Yeah, the french conspiracy strikes again :D btw, I hope we'll have an opportunity to meet all the frenchies near Paris around some beers one of these days :) -- Pierre-Yves Rofes Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Packages up for grab
On Saturday 14 July 2007 12:13:38 Christian Heim wrote: > The following packages need some love and/or a new maintainer: Here are some more :| Previously maintained by Elfyn McBratney (beu): - app-admin/procinfo - app-admin/usermin - app-admin/xtail - app-doc/howto-html - app-doc/howto-html-single - app-doc/php-docs - app-doc/single-unix-specification - app-misc/glimpse - dev-libs/libunicode - dev-util/filepp - dev-util/gperf - dev-util/pstack - dev-util/synopsis - dev-util/webcpp - dev-util/weblint - dev-util/xdelta - net-dns/dnswalk - net-dns/hesiod - net-dns/odsclient - net-misc/balance - net-misc/datapipe - net-misc/dhcpv6 - net-misc/emirror - net-misc/fmirror - net-misc/httptunnel - net-misc/netkit-routed - net-misc/pen - net-misc/pimpd - net-misc/proxyper - net-misc/proxytunnel - net-misc/sslwrap - net-misc/unix2tcp - net-www/dotproject (Assigned to web-apps) - sys-apps/compare - sys-apps/count - sys-apps/hdump - sys-devel/bin86 (Assigned to base-system) - sys-devel/dev86 (base-system ?) - www-apps/coppermine (Assigned to web-apps) - www-misc/visitors (web-apps ?) - www-servers/lighttpd (Assigned to www-servers) Previously maintained by Scott Stoddard (deltacow): - app-admin/watchfolder Previously maintained by Alexandre Buisse (nattfodd): - app-vim/vim-spell-fr (Assigned to vim) - dev-lang/anubis - dev-ml/ocaml-doc (Assigned to ml) - dev-tex/bera (Assigned to tex) - dev-tex/hyphen_show (Assigned to tex) - dev-tex/latexdiff (Assigned to tex) - dev-tex/latexmk (Assigned to tex) - dev-tex/mpm (Assigned to tex) - dev-tex/rubber (Assigned to tex) - dev-util/ketchup (kernel-misc ?) - media-gfx/ufraw (Assigned to graphics) - media-libs/exiftool (Assigned to graphics and perl) - media-sound/lltag (Assigned to sound) Regards, Christian -- Christian Heim GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Packages up for grab
> - dev-cpp/Ice (cpp herd ?) cpp will take that one > - dev-util/cflow I'll take that one signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grab
On Sun, 2007-07-15 at 11:27 +0200, Christian Heim wrote: > - media-libs/exiftool (Assigned to graphics and perl) I'll be happy to take this, I already said as much in the open bugs for it. Kind regards, Hans signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] iuse defaults example
On 2007/07/10, Mike Frysinger <[EMAIL PROTECTED]> wrote: > for some flags yes ... for others, i dislike that idea for the exact > same reason for the other profile-based suggestions: these defaults > should live in the ebuild, not the profile I agree that putting per-package defaults in ebuilds is far more elegant than putting them in profiles. My point is just that it doesn't work that well with the USE_ORDER that have been chosen. Even keeping the "-* in make.conf" case appart (obviously my opinion on how it should behave was not widely shared, i can live with that), there is still a problem with -* in make.defaults files: the day you switch from IUSE="nocxx" to IUSE="+cxx", will you remember that, as a consequence, you have to fix hardened/2.6/minimal profile? And also, in bug #61732 there is this comment from Zac about "-foo" not being supported because pkginternal is at the bottom of the stack. Imho, that's missing a great opportunity to make users' life a bit easier... Take the "gtk" flag, which is on by default in usual desktop profiles, but as the drawback to trigger GTK+-1.2 installation just for a few CLI programs which comes with an optional obsolete GUI: wouldn't it be nice if said packages could state IUSE="-gtk", so that the default behavior would be to install only GTK+-2.x GUIs? I'm pretty sure it would save a tenth of /etc/portage/package.use entries for many users. -- TGL. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
* Chris Gianelloni <[EMAIL PROTECTED]>: > On Wed, 2007-07-04 at 18:23 +0300, Petteri Räty wrote: > > How is being a devrel member important for the table? I don't think it's > > any more special than any other TLP. > > It is very important in the case of Council members as the Council is > the escalation point for Developer Relations appeals. Let me please point out that no infrastructure team member is on the list right now. As infra is often involved in implementing council decisions we should take care that the information flows. IMHO the easiest way to achieve this is electing an infra member to the council. Thanks. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: ML changes
Daniel Drake <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sat, 14 Jul 2007 23:54:44 -0400: > I do like the "gentoo-politics" idea that came up a few weeks ago, which > was to move politics off gentoo-dev and to another list, but I'd view it > from another perspective (and avoid the words 'politics'): make > gentoo-dev for development topics only, and have another list for the > rest. But, I suspect we'd come back to the same problem on both lists, > where some people are too keen to talk and deviate too far away from > technical discussion. I like the "gentoo-project" (yes, that's better than politics) idea as well, and believe it /could/ solve the problem here, given a couple conditions are met. One, -project is not to be required reading for devs as -dev is. Devs (and others) can ignore it if they wish. Two, people be consistent about telling folks to go to -project when it goes OT, setting the followup-to/reply-to. Telling folks much of the current discussion doesn't belong in -dev doesn't help now, because there's nowhere to send them. Once there is, simple "no further replies here, this belongs on the gentoo-project list", no name calling, no further discussion, just that, if enough current regulars do it, should dramatically decrease the noise level here. Already since the idea was proposed, I've wished the other list was up and running, as there are posts I'd have posted there rather than here, this whole thread could have gone there (except one would hope it wouldn't be needed then), etc. I really think it can work... because I've seen it work on other groups and mailing lists before. It just has to be implemented. Then, if after a month or two it's not working, / then/ I'd say it's time to consider bringing in the big moderation guns. But I think it can and will work without those guns, provided we give it the chance and effort to make it so. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Packages up for grab
Christian Heim wrote: > - dev-tex/hyphen_show (Assigned to tex) I'll take this; I had originally contributed it in 2005. Ulrich -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Torsten Veller schrieb: > Let me please point out that no infrastructure team member is > on the list right now. > > As infra is often involved in implementing council decisions we should > take care that the information flows. IMHO the easiest way to achieve this > is electing an infra member to the council. In the contrary. We should see that not too much power/responsibility is concentrated on a single person. Since... a) This guarantees that the council comes to a decision which is not influenced by the (direct and already known) interest of it's members and b) Reduces the risk for Gentoo when someone with more than one key position leaves And if someone has to be in a council/whatsoever to get the relevant information, something else is broken. And tweaking the election procedure to reach that someone from a special project is elected is somehow questionable, don't you think? Cheers, Tiziano signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: ML changes
Will Briggs <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 15 Jul 2007 17:54:10 +1000: > At the moment gentoo-dev is a "one big noisy room" forum. This is seen > as a "problem" > > Propose solutions have included: > > 1) The "Let's divide up the room" solution - (and so we have proposals > for gentoo-politics, gentoo-flamewar and other more "specialised" fora) > > [snip 2] > > The first doesn't work because it's well nigh impossible to enforce what > is on or off topic. Not really. Basically, once we have -politics or whatever, if anyone says it's OT for -dev, I don't see the point in arguing it further here, just post there. I've seen it work. With a bit of cooperation, once one respected regular (basically dev, for our purposes) says it goes to the other list/group/room/whatever, none of the regulars reply any further. The point is, once there's the other group/list to point to, it's not worth fighting over any longer, so even if a regular believes it actually /does/ belong in the "home" group/list, because there's another list/group and to maintain the common peace, that's it, it goes to the other list/group. Very very seldom is it actually worth breaking the common peace and fighting over, and when there /is/ discussion, when someone /does/ go beyond the norm, it's generally handled privately, person-to-person, because the cost of breaking rank publicly is chaos, which benefits no one of the regulars, only deliberate trolls. I'd really really like to have a go at it, to see if we /can/ make it work. I think we can, and /if/ we can, it's clearly a superior solution to forced moderation or other "forced" measures. Peer pressure /can/ work! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Sun, Jul 15, 2007 at 03:07:28AM +0200, Benedikt Boehm wrote: > As it seems, you do not have the time and/or interest to cleanup the > qmail mess, but don't want anyone to touch (net)qmail ebuilds either, i > have put the updated ebuilds for qmail and friends into my overlay. [1] You interpret something into it which isn't true. I'm not “holding” it. Publishing such unverified interpretations publically isn't exactly nice, too. It's just that I don't have time today or tomorrow to look more exactly into it, or, more exactly, I have things with higher priorities to be done first (but also Free Software related!). And as the current maintainer I just said “no” to your code (for now). There's nothing wrong with doing that if I'm not accepting it (due to whatever reason). You didn't ask to take over maintainership. Doing a change like this to an ebuild has to be well thought, reviewed and can't be done withing hours. netqmail is rather fragile to breakage and we don't want our users to loose e-mails due to our failures, do we? Now, you should correct that blog entry (I'm not going into why moving topics from MLs to blogs is very bad) to actually state true facts and then wait a few days. I'll have some time during this week. Greets, Michael -- http://hansmi.ch/ pgpumgWqiSWFH.pgp Description: PGP signature
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tiziano Müller wrote: > Torsten Veller schrieb: >> Let me please point out that no infrastructure team member is >> on the list right now. >> >> As infra is often involved in implementing council decisions we should >> take care that the information flows. IMHO the easiest way to achieve this >> is electing an infra member to the council. > > > And if someone has to be in a council/whatsoever to get the relevant > information, something else is broken. And tweaking the election > procedure to reach that someone from a special project is elected is > somehow questionable, don't you think? > Well, I don't think there is anything wrong with somebody from infra being on the council, but I also agree that it shouldn't be essential. I see the council as being like a board of directors for a company - they don't need to make day-to-day decisions but they do need to have ultimate oversight. The skillset needed to run a board is different from the skillset needed to run day-to-day operations. I see the main skills needed by a council member as: 1. Good people skills! 2. Ability to listen to all sides of an issue and make informed decisions. 3. Ability to be an advocate for the project. 4. Energy and spirit - ability to motivate. 5. Ability to be firm when needed - balanced with ability to stay polite while being firm. 6. Some technical vision for the project. 7. Ability to evaluate proposed solutions to technical problems. Honestly, I'm actually wondering if it is a mistake to limit the council nominations to devs only. Having the devs do the voting is a good move I think - they have to live with the decisions and alienating the devs isn't going to be good for the users and other stakeholders. However, if the devs want to elect a non-dev I think that they should be able to do so. Organizations frequently have boards that are composed of non-daily-contributors. I think that Gentoo is making a mistake in seeing the council as a place where ultimately highly-technical decisions get made. I think that is one role of the council, but if you look at Gentoo that isn't what is really causing the problems. The only really technical flamefest I tend to see on -dev is the periodic what-is-the-blessed-package-manager war - and that really isn't so much a technical battle as much as one of principle - should gentoo have more than one? (AND PLEASE DO NOT REPLY TO THIS OPENING UP THAT BATTLE AGAIN!!!) Most other technical debates on -dev tend to be a little more dispassionate. My feeling is that the council should be setting general direction and providing accountability on technical issues, but individual herd leads should be the ones taking the initiative. Is there a QA issue? The QA herd lead should come up with a potential solution, run it past the council with some advance debate, and then everybody works together to implement it. The council doesn't need to solve every problem - they just need to listen to people who might have the answer - with a large group like Gentoo they probably already exist. And the council shouldn't be afraid to hire others to do the day-to-day work (well, maybe hire without pay if necessary... :) ). The proctors were a good example of this (even if maybe it didn't get implemented as intended or it didn't go as well as hoped). While the council does need energy it shouldn't require personally moderating the whole project. In real life boards hire CEOs to do the heavy lifting and just meet once per month to see how it is going. I'm not advocating that for gentoo, but people do need to look at the council differently than they do now. It doesn't have to have the best developers in gentoo - it needs to have the best council-members in Gentoo... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGmgMFG4/rWKZmVWkRAlGfAJ4vGcSnCYxDXp/y5ILWux1+y6x3WACghOwR 5BQg4vpme3BuUFrz4sQMveA= =iown -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
* Tiziano Müller <[EMAIL PROTECTED]>: > Torsten Veller schrieb: > > Let me please point out that no infrastructure team member is > > on the list right now. > > > > As infra is often involved in implementing council decisions we should > > take care that the information flows. IMHO the easiest way to achieve this > > is electing an infra member to the council. > > In the contrary. We should see that not too much power/responsibility is > concentrated on a single person. > > Since... > a) This guarantees that the council comes to a decision which is not > influenced by the (direct and already known) interest of it's members > and > b) Reduces the risk for Gentoo when someone with more than one key > position leaves If devs in a key position leave, it's often a problem. But I don't see a concentration problem here. > And if someone has to be in a council/whatsoever to get the relevant > information, something else is broken. I didn't write that and didn't meant that. > And tweaking the election procedure to reach that someone from a > special project is elected is somehow questionable, don't you think? No. I also vote this way. I want the council to represent Gentoo as a whole and be represented by Gentoo as a whole. I think it helps the other council members too if there is e.g. an infra member to take care of the infra stance. But: A council without an infra member can do a good job too. Thanks. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Packages up for grab
Christian Heim <[EMAIL PROTECTED]> yazmış: > - app-misc/screenie > - app-admin/xtail > - net-misc/sslwrap > - net-misc/unix2tcp I'll take these lil' ones if noone else wants. -- ali polatel (hawking) pgps4bTWSpOSw.pgp Description: PGP signature
Re: [gentoo-dev] iuse defaults example
On Sun, 15 Jul 2007 11:53:08 +0200 Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > On 2007/07/10, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > for some flags yes ... for others, i dislike that idea for the exact > > same reason for the other profile-based suggestions: these defaults > > should live in the ebuild, not the profile > > I agree that putting per-package defaults in ebuilds is far more > elegant than putting them in profiles. > > My point is just that it doesn't work that well with the USE_ORDER > that have been chosen. Even keeping the "-* in make.conf" case appart > (obviously my opinion on how it should behave was not widely shared, i > can live with that), there is still a problem with -* in make.defaults > files: the day you switch from IUSE="nocxx" to IUSE="+cxx", will you > remember that, as a consequence, you have to fix hardened/2.6/minimal > profile? Well, it's just like any other renaming of USE flags in that regard. > And also, in bug #61732 there is this comment from Zac about "-foo" > not being supported because pkginternal is at the bottom of the stack. > Imho, that's missing a great opportunity to make users' life a bit > easier... Take the "gtk" flag, which is on by default in usual desktop > profiles, but as the drawback to trigger GTK+-1.2 installation just > for a few CLI programs which comes with an optional obsolete GUI: > wouldn't it be nice if said packages could state IUSE="-gtk", so that > the default behavior would be to install only GTK+-2.x GUIs? I'm > pretty sure it would save a tenth of /etc/portage/package.use entries > for many users. IIRC that has been added a little while ago, but with the current default USE_ORDER it's more or less useless. And while I can see why people would want IUSE defaults to have a higher priority than USE in make.defaults and/or make.conf, I suspect the vast majority of users would get completely lost in finding out where a flag was enabled/disabled (the current system is already confusing to a lot of people until they get a detailed explanation). Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] iuse defaults example
On 2007/07/15, Marius Mauch <[EMAIL PROTECTED]> wrote: > On Sun, 15 Jul 2007 11:53:08 +0200 > Thomas de Grenier de Latour <[EMAIL PROTECTED]> wrote: > > > My point is just that it doesn't work that well with the USE_ORDER > > that have been chosen. Even keeping the "-* in make.conf" case > > appart (obviously my opinion on how it should behave was not widely > > shared, i can live with that), there is still a problem with -* in > > make.defaults files: the day you switch from IUSE="nocxx" to > > IUSE="+cxx", will you remember that, as a consequence, you have to > > fix hardened/2.6/minimal profile? > > Well, it's just like any other renaming of USE flags in that regard. But it shows that the "we shouldn't care about per-ebuild defaults in profiles" argument doesn't really stand, which is unfortunate because Mike is probaly right that it would have been a good thing. > And while I can see why people would want IUSE defaults to have a > higher priority than USE in make.defaults and/or make.conf, I suspect > the vast majority of users would get completely lost in finding out > where a flag was enabled/disabled (the current system is already > confusing to a lot of people until they get a detailed explanation). I don't think it's something which would be that hard to explain to users. All it takes is having "emerge -pv" to clearly shows that something unusual is happening when a flag value is overidden by an IUSE-default, for instance with an exclamation mark suffix, and to document that in the man page, with the rest of the --verbose output: ! suffix = profile's global default value for this flag is overidden by an ebuild-specific setting. You can still enable / disable it in your own configuration (make.conf or package.use) if you really want to. Maybe i am over-estimating the average user, but to me it doesn't sound that complicated or obscure. -- TGL. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] PHP security status
Hi, At the moment, we have a quite problematic situation with the php ebuilds. Due to various people doing research on php-issues, there has been a vast number of security issues in the last months (mopb and others). We still have 5.2.2 in the tree. A user, christian hoffmann, is maintaining some ebuilds in the php-experimental-overlay. They've, from what I know, fixed nearly all issues, beside one openbasedir-bypass, where we fail to find a patch (CVE-2007-3378). Now, chtekk has been very rarely available lately. chtekk, could you raise your voice and tell us if you'll be back soon or if we could merge stuff without you in the meantime. Christian is doing a quite well job in the overlay. I'd prefer if we could merge his work into the main tree. I could do that, although I'd prefer to get some review from other devs. php is a hell to maintain I think. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PHP security status
On Sunday 15 July 2007 15:02:45 Hanno Böck wrote: > Hi, > > At the moment, we have a quite problematic situation with the php ebuilds. > Due to various people doing research on php-issues, there has been a vast > number of security issues in the last months (mopb and others). > > We still have 5.2.2 in the tree. A user, christian hoffmann, is maintaining > some ebuilds in the php-experimental-overlay. They've, from what I know, > fixed nearly all issues, beside one openbasedir-bypass, where we fail to > find a patch (CVE-2007-3378). > > Now, chtekk has been very rarely available lately. chtekk, could you raise > your voice and tell us if you'll be back soon or if we could merge stuff > without you in the meantime. As you might know from his away status (either from IRC or the devaway¹ page), Luca is currently doing his mandatory military service for his country till November iirc. > Christian is doing a quite well job in the overlay. I'd prefer if we could > merge his work into the main tree. I could do that, although I'd prefer to > get some review from other devs. php is a hell to maintain I think. 1:http://www.gentoo.org/proj/en/devrel/roll-call/devaway.xml?select=chtekk#chtekk Regards, Christian -- Christian Heim GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] council and proctors
Alle domenica 15 luglio 2007, Ferris McCormick ha scritto: > Here's one I should sleep on -- I didn't: > > Not much. > Very few Comments. > I'll start them. > 1. Council is just wrong. They are also just gone. > > 2. I am just wrong. Most likely. > > 3. Council blew it. They ignore what proctors were doing, killed > COC, and > punted.. I have always thought that proctors/COC is useless, I vote to remove it. -- Timothy `Drizzt` Redaelli - http://dev.gentoo.org/~drizzt/ FreeSBIE Developer, Gentoo Developer, GUFI Staff There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] council and proctors
3. Council blew it. They ignore what proctors were doing, killed COC, and punted.. ++ Poor job or rather interests conflict. On 7/15/07, Ferris McCormick <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Here's one I should sleep on -- I didn't: Not much. Very few Comments. I'll start them. 1. Council is just wrong. They are also just gone. 2. I am just wrong. Most likely. 3. Council blew it. They ignore what proctors were doing, killed COC, and punted.. - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Sparc, Devrel) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6-ecc01.6 (GNU/Linux) iD8DBQFGmXFmQa6M3+I///cRAvbLAJ9aV327q7fteXaN0iVXJ1EXgV+ISgCfZPrw FhIdcA3alnuNmkQu6HLzmqA= =VAq+ -END PGP SIGNATURE- -- Ioannis Aslanidis 0xB9B11F4E -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: ML changes
Christina Fullam wrote: > I suppose the problem is high-volume and excessive flaming/trolling/OT. > The proposed solution asks that every developer take an active role, > yes, so that could easily equal more work - but I have little doubts > that there are developers that will take an interest in doing it. > It's odd though, that several have remarked how the list has been improving recently, and the most off-topic distraction imo has been this entire thread, based on meetings which were not exactly carried out in a transparent manner. Instead, the list was simply told that this what "We" were going to do. It doesn't strike me as a good way to establish consensus nor as inspiring leadership. > However, all that aside, here is another way this change could be > implemented: > I am still unsure as to the need for the change. It hasn't been fully established that this change is the correct solution afaics. The long discussion that led to the establishment of the proctors came up with a markedly different consensus of the way forward. Now this is imposed (a week to comment before the motion is voted on.) > -core stays private. I really dont see the need to change IMO. Agreed. > -project (call it what you will) would be for the off topic, non > development emails that we so commonly see. this list would be optional > for all developers. > -dev (no preference for the name) would be for development discussion > for devs and non-devs alike. I can see that working if you implement some of the proposed technical fixes, eg so that an Off-Topic discussion can be directed to project. > everyone would all start out on a > whitelist. any developer could opt to move a dev or non-dev to the > moderated list (meaning their emails would be delayed allowing for > moderation or simple release after a given time period). The trouble I have with this is that a distinction is drawn between the two groups, and one group (with a history of disdain to the other, as well as of flaming) is given more power. Sounds like a social experiment waiting to happen. > The check and balance for this would be that if any developer was found > to be moderating someone unnecessarily, that developer themself would be > moved to the moderated list by devrel for a time period without any > access rights to change anything further themselves. Repeat offenders > would be reviewed by devrel for further action if needed. this list > would be required for all developers. > So the only course of appeal is to a subset of the minority group. I note that the appeal mechanism hasn't even been discussed, so I am unsure as to just how transparent it will be. Further if it's only devs who have any input, I don't have any confidence in it actually achieving the aims, ie a mailing list which is a good place for *all* to discuss development. As someone else pointed out, any of A, B, or C could squash a post agreeing with X, Y or Z, no doubt feeling justified. I don't believe that overworked devs are going to be that sympathetic to appeals, and it seems like a bureaucratic nightmare. To say that people don't identify with their peers is disingenous, and given that they do, moderation by only one side seems to lack credibility. At least with the proctors, you were drawing from the existing Gentoo moderators, across all channels, so had some assurance of experience and competence, as well as the confidence of users. > I dont think for a moment that it is only non-devs causing this > excessive amount of email which often results in flaming/trolling. I do > agree that everyone should be bound by the same rules. > > Thoughts? > Only that if you want us all to be bound by the same rules, giving yet more power to _individual_ devs is not the way to do it. Here's an idea: ask the people who've got the experience to do the job. They may not always be sympathetic, but they are at least always professional. Also, since it has emerged from this discussion that there is no internal development list, maybe it would be good to set one up? I dunno, it may well be that drobbins et al intentionally made it so that all development discussion had to be done in conjunction with users, and not just to get their input. After all, a developer who cannot deal with non-devs still has some growth to achieve, imo, and Gentoo once had the aim of producing devs who were a credit to the team. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] PHP security status
On Sunday 15 July 2007 15:02, Hanno Böck wrote: > Christian is doing a quite well job in the overlay. I'd prefer if we could > merge his work into the main tree. I could do that, although I'd prefer to > get some review from other devs. php is a hell to maintain I think. Christian just provided an updated, so now would be a good time to give reviews. More security details on bug 180556¹. ¹ https://bugs.gentoo.org/show_bug.cgi?id=180556 -- Sune Kloppenborg Jeppesen Gentoo Linux Security Team -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
After being bribed with beer from edit_21, welp and a few others I accept my nomination too. Thanks Roy -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] iuse defaults example
On Sunday 15 July 2007, Thomas de Grenier de Latour wrote: > My point is just that it doesn't work that well with the USE_ORDER that > have been chosen. Even keeping the "-* in make.conf" case appart > (obviously my opinion on how it should behave was not widely shared, i > can live with that), there is still a problem with -* in make.defaults > files: there are ways to make the USE=nocxx -> USE=cxx transition nice and i plan on going that route > the day you switch from IUSE="nocxx" to IUSE="+cxx", will you > remember that, as a consequence, you have to fix hardened/2.6/minimal > profile? there is no "nocxx" reference anywhere in the profiles/ tree -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] qmail.eclass draft
On Sun, 15 Jul 2007 13:19:08 +0200 Michael Hanselmann <[EMAIL PROTECTED]> wrote: > On Sun, Jul 15, 2007 at 03:07:28AM +0200, Benedikt Boehm wrote: > > As it seems, you do not have the time and/or interest to cleanup the > > qmail mess, but don't want anyone to touch (net)qmail ebuilds > > either, i have put the updated ebuilds for qmail and friends into > > my overlay. [1] > > You interpret something into it which isn't true. I'm not “holding” > it. Publishing such unverified interpretations publically isn't > exactly nice, too. It's just that I don't have time today or tomorrow > to look more exactly into it, or, more exactly, I have things with > higher priorities to be done first (but also Free Software related!). > And as the current maintainer I just said “no” to your code (for > now). There's nothing wrong with doing that if I'm not accepting it > (due to whatever reason). You didn't ask to take over maintainership. In fact you haven't been that nice either, but honestly i don't care. Therefore i have just moved the ebuilds to my overlay until you can review them ... > Doing a change like this to an ebuild has to be well thought, reviewed > and can't be done withing hours. netqmail is rather fragile to > breakage and we don't want our users to loose e-mails due to our > failures, do we? ... so that it can be tested by those who feel like. > Now, you should correct that blog entry (I'm not going into why moving > topics from MLs to blogs is very bad) to actually state true facts and > then wait a few days. I'll have some time during this week. > > Greets, > Michael > -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Packages up for grab
Christian Heim wrote: > Here are some more :| > > Previously maintained by Elfyn McBratney (beu): > - app-doc/howto-html > - app-doc/howto-html-single > - app-doc/single-unix-specification I'll take these. -- dirtyepic salesman said this vacuum's guaranteed gentoo org it could suck an ancient virus from the sea 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Torsten Veller <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Sun, 15 Jul 2007 13:40:29 +0200: > * Tiziano Müller <[EMAIL PROTECTED]>: >> Torsten Veller schrieb: >> > Let me please point out that no infrastructure team member is on the >> > list right now. >> > >> > As infra is often involved in implementing council decisions we >> > should take care that the information flows. IMHO the easiest way to >> > achieve this is electing an infra member to the council. >> >> In the contrary. We should see that not too much power/responsibility >> is concentrated on a single person. >> >> Since... >> a) This guarantees that the council comes to a decision which is not >> influenced by the (direct and already known) interest of it's members >> and >> b) Reduces the risk for Gentoo when someone with more than one key >> position leaves > > If devs in a key position leave, it's often a problem. But I don't see a > concentration problem here. The problem in practice is this: As Chris G. I believe it was pointed out, being a Council member is "hella" stressful. (From memory so the numbers are fuzzy, ask Chris.) Of the this term's seven elected council members, two ended up retiring from Gentoo entirely, while others almost did and/or resigned from their council position. Few of the remaining ones are interested in ever running for the position again. So serious as a heart attack, there is a real problem. Unfortunately, as currently structured, the stress on council is great enough that people /do/ leave in the middle of their term, so it's best to consider that a real likelihood when thinking about nominations and votes for council. I respect Chris G a lot, but it's very obvious the stress has affected how he deals with Gentoo as well, and he's stated no way is he interested in the position again. I think everybody nominated even more than those voting would do well to pay serious attention to what he says on the subject, because how they handle their duties as council members has a very real likelihood of permanently affecting their relationship with Gentoo. I know if I were a dev and nominated, I'd be seriously contemplating whether it were worth doing, in the light of how dramatically it negatively affected the Gentoo life of last years elected council. There's no escaping the reality, however one might wish to pretend it won't affect them. I'd be asking myself if the council position was worth possibly getting so burnt out and fed up with Gentoo that I quit. Some might believe in what they want to do enough to find it worth it, while others believe in their ability to handle the situation regardless. More power to them. I do hope that those that accept the nomination and are ultimately elected are ready for it, because it really hurts to lose good people, and by definition, anyone well respected enough to win an elected seat on the council is a "good" person in terms of their contribution to Gentoo, or they'd not be winning that seat. Losing anyone that well respected by their peers is GOING to hurt, so I really do hope the folks that are running are prepared for what they are getting themselves into, and we /don't/ lose anyone due to council duties this coming year. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] iuse defaults example
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 2007-07-15 21:22:07 Mike Frysinger napisał(a): > On Sunday 15 July 2007, Thomas de Grenier de Latour wrote: > > the day you switch from IUSE="nocxx" to IUSE="+cxx", will you > > remember that, as a consequence, you have to fix hardened/2.6/minimal > > profile? > > there is no "nocxx" reference anywhere in the profiles/ tree > -mike grep -r "USE.*-\*" /usr/portage/profiles - -- Arfrever Frehtes Taifersar Arahesis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.5 (GNU/Linux) iD8DBQFGmoKZ/axNJ4Xo/ZERAv5dAJ9f+8hMkuRtrJtlYfy+KgdxYc3jFACeM3fn UZ2vEVoPm150Pe0vD+pKtnI= =GhHz -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] iuse defaults example
On Sunday 15 July 2007, Arfrever Frehtes Taifersar Arahesis wrote: > 2007-07-15 21:22:07 Mike Frysinger napisał(a): > > On Sunday 15 July 2007, Thomas de Grenier de Latour wrote: > > > the day you switch from IUSE="nocxx" to IUSE="+cxx", will you > > > remember that, as a consequence, you have to fix hardened/2.6/minimal > > > profile? > > > > there is no "nocxx" reference anywhere in the profiles/ tree > > grep -r "USE.*-\*" /usr/portage/profiles profile deserves what it gets then -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] ML changes
On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: > All- > > We're going to change the -dev mailing list from completely open to where only > devs can post, but any dev could moderate a non-dev post. devs who moderate > in > bad posts will be subject to moderation themselves. in addition the > gentoo-project list will be created to take over what -dev frequently becomes. > there is no requirement to be on this new list. > > This will probably remove the need for -core(everything gets leaked out > anyway) > but that's a path to cross later. > > We're voting on this next council meeting so if you have input, now would be > the time. > > --taco no offense, but this is one of the worst proposals i've ever read on this list; why? because, one of gentoo's major problems is that it is becoming more and more a toy exclusively for its own developers. by banning non-dev contributors from this list some of you may feel better - but gentoo as a whole will probably suffer. silencing people doesn't make their opinions invalid. what gentoo needs in my opinion is a clear structure, strict and unmistakable rules about what $dev may do and what $dev must not do, and ways to enforce these rules; this, and not moderating or restricting communication channels, would improve the way people are working together. as this may be my last post - and it seems to fit in quite nicely - i also want to say: gentoo's problem is not that ciaranm is a troll. the problem is that ciaranm is not a troll. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: math-proof herd
Resending, as it seems gmail eats my outcoming mail.. Hi Christian. The corresponding bug is #138059, quoting nattfodd: "The list of software we could add is quite long, too..." Well, looks like the herd did not collect as many packages as it was expected to do. Considering that, I agree that the packages should simply be (back) migrated to under plain sci, unless someone expresses interest in keeping the herd alive (or even creating category which would, naturally, need even more packages). I'll reopen that bug (https://bugs.gentoo.org/show_bug.cgi?id=138059) and I think it makes sense to keep it open for a week or so. If anybody is interested, please comment on that bug. If nobody does, sure, go ahead and reassign the packages and delete the math-proof herd, or I can do this in about two weeks (likely already in Aug, as I am gong to be "on the move" for the large part of two coming weeks).. George PS Added gentoo-dev to CC so that more devs might take a note. Sunday, 15. July 2007, Christian Heim Ви написали: > Dear George, I'm just looking through herds.xml in light of nattfodd's > retirement and I stumbled upon the math-proof herd which only contains > nattfodd as a member, no-one else. > > So my question to you is, should I rather delete the herd and assign the > packages back to sci or add the sci herd as a member of the math-proof herd > ? > > I'd rather go with moving the package back to the sci herd, since its only > those three: > - sci-mathematics/agda > - sci-mathematics/coq > - sci-mathematics/otter > > Thanks and regards, > >Christian -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Matthias Langer wrote: by banning non-dev contributors from this list some of you may feel better - but gentoo as a whole will probably suffer. silencing people doesn't make their opinions invalid. I keep seeing this argument over and over again. Many people are just completely misunderstanding. This is not a blanket silencing of any non-dev on the list. This is simply delaying the posting of messages from non-devs (and even devs that have "improperly" moderated in the past). If nobody moderates a particular message to the list within a set amount of time, the message passes through. Making the list "moderated" isn't the same as making a channel moderated on IRC. Anyone will still be able to speak, just with a slight delay, which allows us to maintain a good signal-to-noise ratio, and hopefully prevent re-occurrences of some of the nastier flamewars we've seen on the list lately. -- Andrew Gaffney http://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Catalyst/Installer + x86 release coordinator -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New developer: Pierre-Yves Rofes (p-y)
Petteri Räty wrote: > Please give him the usual flamy welcome. ... py... -- dirtyepic salesman said this vacuum's guaranteed gentoo org it could suck an ancient virus from the sea 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: ML changes
Duncan wrote: I like the "gentoo-project" (yes, that's better than politics) idea as well, and believe it /could/ solve the problem here, given a couple conditions are met. One, -project is not to be required reading for devs as -dev is. Devs (and others) can ignore it if they wish. Two, people be consistent about telling folks to go to -project when it goes OT, setting the followup-to/reply-to. Telling folks much of the current discussion doesn't belong in -dev doesn't help now, because there's nowhere to send them. Once there is, simple "no further replies here, this belongs on the gentoo-project list", no name calling, no further discussion, just that, if enough current regulars do it, should dramatically decrease the noise level here. Already since the idea was proposed, I've wished the other list was up and running, as there are posts I'd have posted there rather than here, this whole thread could have gone there (except one would hope it wouldn't be needed then), etc. I really think it can work... because I've seen it work on other groups and mailing lists before. It just has to be implemented. Then, if after a month or two it's not working, / then/ I'd say it's time to consider bringing in the big moderation guns. But I think it can and will work without those guns, provided we give it the chance and effort to make it so. Just a reminder, Bug #181368 is the bug I filed for the -project ML over a month ago. I just updated it with a suggestion that -project not be required subscription for new devs, just that new devs need to be informed of both its existence and purpose (this was left out of my original submission). Those interested may want to add themselves to the CC list to track any developments that happen there (assuming the fire doesn't spread). @Council As for the rest of thisthread..., mayhaps it would be wise for Council and Infra to postpone the moderation idea for a few months? (let 2007-2008 council handle the matter) As this really isn't the kind of thing we should be pulling during a council/trustee switch out (just look at the size of the thread). @Infra In what may be appropriately considered a vain attempt to end this thread, can we just go ahead and create -project, and give it a few weeks to see what happens? Worry about -dev and moderation later on. Cheers, --Kumba -- Gentoo/MIPS Team Lead "Such is oft the course of deeds that move the wheels of the world: small hands do them because they must, while the eyes of the great are elsewhere." --Elrond -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2007-07-15 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2007-07-15 23h59 UTC. Removals: net-firewall/firestarter2007-07-10 21:54:09 mr_bones_ app-emacs/ilisp-cvs 2007-07-12 06:37:54 opfer app-emacs/ilisp 2007-07-12 06:41:32 opfer app-arch/bsdtar 2007-07-13 13:14:12 flameeyes sys-apps/pam_mount 2007-07-13 16:24:50 hanno Additions: dev-haskell/x11 2007-07-09 12:39:24 dcoutts dev-haskell/opengl 2007-07-09 12:39:57 dcoutts dev-haskell/openal 2007-07-09 12:40:29 dcoutts dev-haskell/glut2007-07-09 12:41:01 dcoutts dev-haskell/alut2007-07-09 12:41:32 dcoutts app-admin/eselect-news 2007-07-09 21:23:17 peper dev-python/storm2007-07-10 14:41:39 dev-zero media-plugins/vdr-lcdproc 2007-07-10 17:43:07 zzam x11-misc/transset-df2007-07-11 02:12:02 angelos net-wireless/iwl3945-ucode 2007-07-11 03:16:16 compnerd net-wireless/iwl4965-ucode 2007-07-11 03:19:53 compnerd net-wireless/iwlwifi2007-07-11 03:26:05 compnerd dev-java/tapestry 2007-07-11 12:05:50 ali_bush dev-python/kaa-base 2007-07-11 23:40:23 rbu dev-python/kaa-imlib2 2007-07-11 23:41:12 rbu dev-python/kaa-metadata 2007-07-11 23:41:35 rbu sys-auth/pam_chroot 2007-07-12 04:37:09 hawking app-emacs/ngnus 2007-07-12 19:23:03 ulm sys-libs/libhx 2007-07-13 01:55:05 hanno sys-libs/libhugetlbfs 2007-07-13 06:00:35 vapier app-arch/libarchive 2007-07-13 13:13:29 flameeyes sys-auth/pam_mount 2007-07-13 16:22:58 hanno net-libs/xyssl 2007-07-13 18:31:09 pylon media-sound/gimmix 2007-07-13 19:35:34 angelos games-board/chessdb 2007-07-13 22:31:08 tupone dev-ruby/twitter2007-07-14 04:20:46 nichoj x11-apps/xbacklight 2007-07-14 05:14:11 dberkholz dev-python/hachoir-core 2007-07-14 13:17:47 cedk dev-python/hachoir-parser 2007-07-14 13:20:08 cedk dev-python/hachoir-regex2007-07-14 13:22:49 cedk app-misc/hachoir-metadata 2007-07-14 13:25:47 cedk app-misc/hachoir-urwid 2007-07-14 13:28:01 cedk app-misc/hachoir-subfile2007-07-14 13:32:15 cedk -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: net-firewall/firestarter,removed,mr_bones_,2007-07-10 21:54:09 app-emacs/ilisp-cvs,removed,opfer,2007-07-12 06:37:54 app-emacs/ilisp,removed,opfer,2007-07-12 06:41:32 app-arch/bsdtar,removed,flameeyes,2007-07-13 13:14:12 sys-apps/pam_mount,removed,hanno,2007-07-13 16:24:50 Added Packages: dev-haskell/x11,added,dcoutts,2007-07-09 12:39:24 dev-haskell/opengl,added,dcoutts,2007-07-09 12:39:57 dev-haskell/openal,added,dcoutts,2007-07-09 12:40:29 dev-haskell/glut,added,dcoutts,2007-07-09 12:41:01 dev-haskell/alut,added,dcoutts,2007-07-09 12:41:32 app-admin/eselect-news,added,peper,2007-07-09 21:23:17 dev-python/storm,added,dev-zero,2007-07-10 14:41:39 media-plugins/vdr-lcdproc,added,zzam,2007-07-10 17:43:07 x11-misc/transset-df,added,angelos,2007-07-11 02:12:02 net-wireless/iwl3945-ucode,added,compnerd,2007-07-11 03:16:16 net-wireless/iwl4965-ucode,added,compnerd,2007-07-11 03:19:53 net-wireless/iwlwifi,added,compnerd,2007-07-11 03:26:05 dev-java/tapestry,added,ali_bush,2007-07-11 12:05:50 dev-python/kaa-base,added,rbu,2007-07-11 23:40:23 dev-python/kaa-imlib2,added,rbu,2007-07-11 23:41:12 dev-python/kaa-metadata,added,rbu,2007-07-11 23:41:35 sys-auth/pam_chroot,added,hawking,2007-07-12 04:37:09 app-emacs/ngnus,added,ulm,2007-07-12 19:23:03 sys-libs/libhx,added,hanno,2007-07-13 01:55:05 sys-libs/libhugetlbfs,added,vapier,2007-07-13 06:00:35 app-arch/libarchive,added,flameeyes,2007-07-13 13:13:29 sys-auth/pam_mount,added,hanno,2007-07-13 16:22:58 net-libs/xyssl,added,pylon,2007-07-13 18:31:09 media-sound/gimmix,added,angelos,2007-07-13 19:35:34 games-board/chessdb,added,tupone,2007-07-13 22:31:08 dev-ruby/twitter,added,nichoj,2007-07-14 04:20:46 x11-apps/xbacklight,added,dberkholz,2007-07-14 05:14:11 dev-python/hachoir-core,added,cedk,2007-07-14 13:17:47 dev-python/hachoir-parser,added,cedk,2007-07-14 13:20:08 dev-python/hachoir-regex,added,cedk,2007-07-14 13:22:49 app-misc/hachoir-metadata,added,cedk,2007-07-14 13:25:47 app-misc/hachoir-urwid,added,cedk,2007-07-14 13:28:01 app-misc/hachoir-subfile,added,cedk,2007-07-14 13:32:15 Done.
Re: [gentoo-dev] ML changes
Andrew Gaffney wrote: > Matthias Langer wrote: >> by banning non-dev contributors from this list some of you may feel >> better >> - but gentoo as a whole will probably suffer. silencing people doesn't >> make their opinions invalid. > > I keep seeing this argument over and over again. Many people are just > completely misunderstanding. > > This is not a blanket silencing of any non-dev on the list. This is > simply delaying the posting of messages from non-devs (and even devs > that have "improperly" moderated in the past). If nobody moderates a > particular message to the list within a set amount of time, the message > passes through. > > Making the list "moderated" isn't the same as making a channel moderated > on IRC. Anyone will still be able to speak, just with a slight delay, > which allows us to maintain a good signal-to-noise ratio, and hopefully > prevent re-occurrences of some of the nastier flamewars we've seen on > the list lately. > Oh dear. "slight delay" in an email list forum? That's like saying "you can take part in this face-to-face conversation but you have to wait 30 seconds before you can say anything" In effect you reduce that person to an on-looker who can throw in the occassional comment. The comments themselves are reduced in their relevance or impact because by the time they are heard, the conversation has moved on. In effect, it's a ban: at the very least a two-tier system demarcated along ill-chosen lines (dev / non-dev). Calling the proposal a "ban" is not misunderstanding - it's simply foresight. At the very least, this is exactly the sort of reaction you get when you exercise poor change management in a context where all participants (dev and non-dev) are heavily invested in the success of the whole. W. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
Matthias Langer wrote: > no offense, but this is one of the worst proposals i've ever read on > this list; why? because, one of gentoo's major problems is that it is > becoming more and more a toy exclusively for its own developers. Gentoo's always been exclusively for the developers. Nobody's paying us to do this. It just so happens that the things we want to do also benefit other people, and so they use them. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grab
I'm the gnap leader/maintainer since Thierry leave gentoo. We are working in new releases. El sáb, 14-07-2007 a las 12:13 +0200, Christian Heim escribió: > The following packages need some love and/or a new maintainer: > > Previously maintained by Thierry Carrez (Koon): > - dev-embedded/gnap > - dev-embedded/gnap-dev > - dev-embedded/gnap-ext > -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Packages up for grab
On Monday 16 July 2007 08:19:19 josé Alberto Suárez López wrote: > I'm the gnap leader/maintainer since Thierry leave gentoo. We are > working in new releases. > > El sáb, 14-07-2007 a las 12:13 +0200, Christian Heim escribió: > > The following packages need some love and/or a new maintainer: > > > > Previously maintained by Thierry Carrez (Koon): > > - dev-embedded/gnap > > - dev-embedded/gnap-dev > > - dev-embedded/gnap-ext Then *PLEASE* update the metadata.xml ... Regards, Christian -- Christian Heim GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
