[gentoo-dev] Re: A Little Council Reform Anyone?
On Thu, 2009-07-02 at 22:14 +0200, Christian Faulhammer wrote: > Hi, > > in general you speak about the council but do you have any concrete > plans/goals you want to achieve? I think we are in the information gathering phase right now on how to best proceed. So nothing concrete as of this point. More abstract ideas at this point. > Ned Ludd : > > The dev population is quite a strange beast. I never expected to win. > > Nor did I, especially because you were quite low on my ballot. > Congratulations. > > > The devs have a voice one time of the year: when it comes time to > > vote. But what about the rest of the year? What happens when the > > person you voted for sucks? You are mostly powerless to do anything > > other than be really vocal in what seems like a never ending battle. > > That needs to change. I'm not quite sure how. But I'd like to see the > > dev body have a year-round voice in the council. Either via quick > > votes year-round on topics or simply by having discussion in the > > channel. Devs should have a right to voice their concerns to the > > council and engage in interactive conversations without being labeled > > troll. > > We have the forums for quick votes, votify is too much to get a > picture of opinions. So use -dev-announce and forums. > > > Another one of the things I'd like to see and help reform with the > > council. First off it spends way too much time on EAPI/PMS. There is > > no reason to make the council an extension of the portage team. > > As member of the PMS team I agree, we have to reach out to more > people. No matter how well Ciaran does the job as editor-in-chief > the process needs to be broadened to involve other groups, too. > > > For example prefix comes to mind. It was a project I did not like at > > first. I'm not even a user. And there are things I surely don't like > > about it as is. But there is community support and it's the icing on > > the cake for some. So I'll back the fsck up and give credit where > > it's due. This is a perfectly good example of a project/fork that > > needs to come back home. Perhaps it's time to cherry pick some more > > stuff/people out of Sunrise? > > Fully agree here, my devhood is a product of Sunrise. > > > desultory points out any two council members can decide to approve > > anything, and that decision is considered to be equivalent to a full > > council vote until the next meeting. I vaguely recall that rule. I'm > > not sure about you, but I think that is a little to much power to put > > in the hands of a few. Any dev mind if we dump that power? > > Maybe extend that to three, but leave such a emergency measure in > place. > > > Meetings will likely go back to one time per month and be +m with +v > > be handed out per request with open chat pre/post meetings. The > > reason for this is to keep the meetings on-track. I won't engage in > > endless discussions. Facts can be presented. They will be reviewed on > > merit, technical and social. > > Agree. > > > The reason the meetings should go back to monthly is to allow those > > who are council members in Gentoo to accomplish things other than the > > council only. We all have personal lives and we all have our > > respective roles we play outside of the council. Another note on > > meetings. The time they are held currently don't fit well with my > > work schedule. > > That you have to discuss with your fellow council members. > > > So lets have some damn fun again !...@#$ > > Oh yeah! > > V-Li -- Ned Ludd Gentoo Linux
[gentoo-dev] A Little Council Reform Anyone?
The dev population is quite a strange beast. I never expected to win. Why would you vote for somebody who did not even publish a manifesto? I don't know but I love you for it. My only intention was to help offset dev-zero being able force the will of outside forces upon us. Well that has been accomplished for now (w00t). But I never ever expected to be ranked so high. "/me blushes" So that means you guys/gals expect stuff from me. Well as I never wrote a manifesto but you still voted for me, I guess I should share some of my ideas on what I'd like to see happen over the following year. The devs have a voice one time of the year: when it comes time to vote. But what about the rest of the year? What happens when the person you voted for sucks? You are mostly powerless to do anything other than be really vocal in what seems like a never ending battle. That needs to change. I'm not quite sure how. But I'd like to see the dev body have a year-round voice in the council. Either via quick votes year-round on topics or simply by having discussion in the channel. Devs should have a right to voice their concerns to the council and engage in interactive conversations without being labeled troll. Another one of the things I'd like to see and help reform with the council. First off it spends way too much time on EAPI/PMS. There is no reason to make the council an extension of the portage team. Portage is still the official package manager of Gentoo. Granted it's good to accommodate others to an extent and I've always kept an open mind on other tools. Alternatives are good as there is always the right tool for the task at hand. But the council really should not be getting involved most of the time unless there is a conflict which can't be worked out among the masses and those trying to get portage to adopt new features. If the dev body wants it otherwise then I'd like to turn my vote over to you the devs. Each and every time the council wants/has to vote on an EAPI/PMS feature then I'll happily put my vote in your hands. You fire up that old votify system and use my vote as yours. Note however that zmedico is not in favor of his time being wasted on deciding what PMS/EAPI features are good. He simply likes bugs and solving those. He likes giving us new features and tends to be more in favor of the devs and community figuring out what is best for us. An EAPI review committee could work well also. As long as we could get non bias people in there. The council should be more about community vs technical issues only. We have lots of top level projects within Gentoo which have simply given up on the council as being an outlet to accomplish anything useful. It should be our job to look at the projects in Gentoo. Look at the ones that have a healthy community and encourage and promote them in ways. For example prefix comes to mind. It was a project I did not like at first. I'm not even a user. And there are things I surely don't like about it as is. But there is community support and it's the icing on the cake for some. So I'll back the fsck up and give credit where it's due. This is a perfectly good example of a project/fork that needs to come back home. Perhaps it's time to cherry pick some more stuff/people out of Sunrise? desultory points out any two council members can decide to approve anything, and that decision is considered to be equivalent to a full council vote until the next meeting. I vaguely recall that rule. I'm not sure about you, but I think that is a little to much power to put in the hands of a few. Any dev mind if we dump that power? Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. The reason the meetings should go back to monthly is to allow those who are council members in Gentoo to accomplish things other than the council only. We all have personal lives and we all have our respective roles we play outside of the council. Another note on meetings. The time they are held currently don't fit well with my work schedule. I'm not subscribed directly to the gentoo-dev mailing list anymore outside of post-only. And I don't plan to re-subscribe. I do browse the archives regularly however. If there is some topic that should be brought to my attention please point it out to me directly on irc or CC: me. Thank you all and I will try not to let you down. Unless you were one of the ones who wanted to me lose. Then sorry, but I'm going to have fun disappointing you, by doing what is best for Gentoo. If you have any ideas on how you think the council should function or reform itself. Please start a new thread or email those who think will listen to those ideas. I'm open for some real change as long as it's for the the positive. So lets have som
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Thu, 2009-02-05 at 00:37 +, Angelo Arrifano wrote:
> On Qua, 2009-02-04 at 18:36 +0200, Petteri Räty wrote:
> Some packages are not automake driven. We have to detect those.
> >
> > > make DESTDIR=${D} PREFIX=/usr \
> > > STRIP=true ENABLE_NLS=${USE_NLS} \
> > > "$@" install
> > > fi
> > >
> >
> > Should use emake. Stripping should be left to the package manager.
STRIP=true replaces STRIP=strip while also returning a non error status.
This is done in order to ensure that portage handles the stripping using
the correct cross-strip. We also have to sed a bunch of templates out
that use install -s etc which always calls the wrong strip.
But STRIP=true is proper as in /bin/true without the path.
Side note I've already talked with upstream and future versions will
probably drop any default stripping or move towards better unification.
Thanks.
Re: [gentoo-dev] Announcement of The G Palmtop Environment ebuilds
On Tue, 2009-02-03 at 17:10 +, Angelo Arrifano wrote: > On Ter, 2009-02-03 at 11:28 -0500, Richard Freeman wrote: > > Angelo Arrifano wrote: > > > We at -embedded would like to introduce GPE - The G Palmtop Environment. > > > < > > palmtop/handheld computers running the GNU/Linux or any other UNIX-like > > > operating system.>> > > > > > > > Sounds neat? How long until I'm running gentoo on my android? :) > > > > Right away: http://tinderbox.dev.gentoo.org/embedded/linwizard/overlay/ > Take the gpe-base/gpe meta ebuild which should pull all the stuff. > > Happy xcompiling, Assuming you have the G2 you could skip all that and simply merge from these .tbz2 into a $ROOT http://tinderbox.dev.gentoo.org/embedded/armv6j-softfloat-linux-gnueabi -- Ned Ludd Gentoo Linux
Re: [gentoo-dev] Commitlog-mailinglist
On Tue, 2007-08-07 at 08:28 +0200, Lars Weiler wrote: > * Petteri Räty <[EMAIL PROTECTED]> [07/08/06 19:20 +0300]: > > Well perhaps we should just look at the overall usage of the mail box > > instead of how it's used. I think there is already some limit in our > > policy for how big you can keep your mailbox. > > Last night some of us infra-folk had a chat in #gentoo-infra > about this commitlog-mailinglist. > solar stated that the > ammount of messages in the dev-mailboxes was the reason to > shut down that list some years ago No no. perhaps I was not clear enough. Sorry if that was the case. I was alluding to more of it being a resource pig.. Which it is of course. We also discussed some possible solutions to make this not a resource pig. I'm in favor of the 14-60 day archives and treat it much in the same way we do for ~'/.maildir/.spam/ folders where we simply flush old mails. I'll get a chance to meet up with taco and robbin tmw.. I do hope to poke them to see where they stand on what they see as an ideal solution.. Note that the primary dev mail checking server is already sitting at ~2.00 loads. > (I have to fetch my > archives to prove that -- AFAIR we only had troubles with > the script, as CVS moved away from our dev-box with local > mail-delivery to a dedicated server). > > We thought about distributing the mails via a public > IMAP-box or via NNTP only. > > But if that list is not too urgent, it might be the best > idea to produce an RSS-feed out of the commitlogs. Somebody > noted that we should include commits to other areas as well > and not those to the gentoo-x86 repository only. So, if you > can wait, I can search my minimalistic Perl-skillz and write > a script for creating the RSS-feed. > > On the other hand we can just switch on the mailing-list and > see how it develops… > > Regards, Lars > -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Commitlog-mailinglist
On Mon, 2007-08-06 at 16:43 +0200, Lars Weiler wrote: > * Mike Frysinger <[EMAIL PROTECTED]> [07/08/06 08:23 -0400]: > > doit (and update lists.xml in the process) > > I can't. The list seems to be closed or limited to a > special address. Furthermore it seems that our listmaster > is either MIA or at LWE. One thing to note.. If we do make mailing list for this. It should not be archived in any such way. devs that subscribe to the mailing list better not be storing mail in imap on infra resources. We simply don't have that kinda spare space to mirror all cvs commits 2-300 times. -- Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] have any developers subscribed to -project?
On Fri, 2007-07-20 at 20:58 +0100, George Prowse wrote: > Do any devs subscribe to -project because no replies have yet to be > heard from developers... Please stop flooding my inbox. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-nfp] Nominations open for the 2007/08 Trustees
On Tue, 2007-07-17 at 10:08 -0500, Grant Goodyear wrote: > Ned Ludd wrote: [Mon Jul 16 2007, 04:00:44PM CDT] > > Long term I worry about the foundation. No offense to anybody. I'm sure > > I don't know or understand the problems you/we have encountered along > > the way. But I think we need to face it 99.9% of our devs are not > > suited to run a foundation such as this. That's not a bad thing in any > > such way. Most of us came to this project cuz we are geeks doing geeky > > things is what we do best.. > > I'm sure some of you get roped into doing the foundation because > > you truly love Gentoo and want to see things be taken care of. However > > to be frank. I don't think I've seen a single substantial thing > > accomplished sense cshields left Gentoo. Please don't take that the > > wrong way. I know we are all busy people. Perhaps you guys have done > > shitloads and I/we just don't know about it. Perhaps it's still the same > > old story.. We are waiting on ABC banks. We can't re-incorp without > > XYZ first. > > Actually, we have a bank, paypal successfully talks to it, Thats good to hear about paypal/banking. And it's good to know that you guys are still there looking out for Gentoo. > and > I believe that we're completely caught up w/ all of the various funding > requests that we've received. You're point is still a good one, > however. > > > Anyway point I'm trying to make here is that I think we might be > > better off using a 3rd party as our foundation. IE people who have > > the experience/motivation and time to focus on such things > > that a foundation should be. > > > > Anyway. I'd like to nominate nobody in-house. > > Yeah, I tend to agree. Not-so-coincidentally, Gentoo's been invited to > join the Software Freedom Conservancy, which would provide just the sort > of 3rd-party management that you're suggesting. I put a write-up on my > blog detailing what we know so far: > > http://www.grantgoodyear.org/g2blog/gentoo/20070717-sflc.html > > I'm cross-posting to -dev, and suggesting that comments be sent > there as well, since most people don't read -nfp. > > If you think this is a good idea, a bad idea, or you just want to know > more, now's the time to express your opinion. > > -g2boojum- We're happy to discuss methods that have worked for other projects with you to help you select the solution that is right for you. I defiantly think this makes the most sense for Gentoo at this time. One area that seems a tad fuzzy in details is how Gentoo would handle dealing with Paragraph 6 - Representation of the Project in the Conservancy. If we went to FSC route. Should we bother in even having a foundation? If so what role shall it play other than to be the liaison between internal funding requests? I think clearly it would not be the best of ideas to allow all our devs unilateral spending abilities. Would you mind inquiring about the "methods that have worked for other projects" ? We are a 501(c)6 right now if I remember correctly and that has been a limiting factor in us receiving donations in this past. By teaming up with them we gain the 501(c)3 status. That seems like a good thing in and of itself as it allows our sponsors to write off donations to the project. Which in turn could lead to a lot more donations, which then turns into Gentoo being able to offer bigger and better things at the end of the day. Thanks for taking the time to work with them, and informing us that the foundation is still active (it's somewhat hard to tell sometimes). -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: For Jakub (and the other procmail-impaired)
On Tue, 2007-07-17 at 01:30 +0100, Steve Long wrote: > Chris Gianelloni wrote: > > > :0 > > * ^List-Id:.gentoo-dev.gentoo.org. > > * ^Subject:.*ML changes > > /dev/null > > > Sorry was there some reason the rest of us had to read this? If so, please > explain it like a responsible Council member. Or is this your swansong? If > so it's l4m3. Is there some reason you feel fscking compelled to respond to every single mail on this list. You know it's guys like mostly "just you" that are driving us away.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] So...
On Mon, 2007-07-16 at 15:06 -0400, Doug Goldstein wrote: > So it's 97 degrees outside.. it's pretty hot... Since everyone loves to > debate non-technical things on this list.. Let's debate Fahrenheit vs > Celcius... > > Discuss! Well from my POV you have about 13 assholes 14 including me that felt the need need to comment on this stupid ass thread. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
[gentoo-dev] About to retire
Well it's clear that nearly everybody is a fucking tard on this list. So before I depart. Here is a list of shit that's going to need to be maintained or dropped from the tree. Do what you will I could give two shits less. dev-embedded/gpio dev-util/elfkickers net-firewall/arptables net-firewall/ebtables net-misc/netkit-telnetd net-misc/vconfig net-proxy/middleman (dead upstream) net-wireless/chillispot sys-devel/sparse -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Fri, 2007-07-13 at 02:17 +0200, Robert Buchholz wrote: > I have to second the voices that a lot of user mails are productive. > I did > not do any stats, but I feel that most mails to -dev are currently by > Gentoo > devs anyway, so it will not seriously reduce the amount of mail in > total. FYI we do have stats.. http://archives.gentoo.org/stats/gentoo-dev-per-month.xml http://archives.gentoo.org/stats/gentoo-dev-per-year.xml http://archives.gentoo.org/stats/ -- Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
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 A lot of people seem to be confused about this mail of yours. Namely mainly how it does or does not relate to the core mailing list. Perhaps you could clarify the idea a little bit for those who seem confused. Thanks in advance. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
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. > > We're voting on this next council meeting so if you have input, now would be > the time. This is an absolutely wonderful idea and I can't wait till we implement it. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
[gentoo-dev] New Linux-PAM stabling plans
Forwarded by request of somebody thats smart/lucky enough to not be on this list but still monitoring it. Forwarded Message From: Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> Subject: New Linux-PAM stabling plans Date: Wed, 4 Jul 2007 20:51:36 +0200 Hi everybody; sorry to mail here rather than -dev, but I'm not subscribed to it and I have no intention to subscribe in the next future. Please forward a copy of this message to gentoo-dev if you can and want, thanks. Since while I was gone nobody took care of PAM, I had to resume work on it (sigh), and almost at the same time I got reported that PAM 0.78 doesn't allow to set some limits in limits.conf to "unlimited" value. This is a good enough reason to work actively on marking 0.99 stable. Unfortunately, 0.99 upgrade isn't entirely trivial, as pam_stack.so is gone, pam_userdb is moved and so is pam_console, plus a few more modules are no more present at all. To solve this issue, I just wrote an upgrade guide in the PAM project that will appear soon at [1]. That guide should contain all the information needed to pass through the upgrade easily. I also have an ebuild ready to commit that will make a lot of warnings and various noise when the pam.d file in the system still refers to the removed packages, pointing to the upgrade guide. It also dies if the user still has pam_stack or other modules that are not moved but really not available. (I'm still not sure where I should die: pkg_setup would stop users from building pkgs, pkg_preinst would waste people time if they didn't notice the warnings at setup stage, as right now the warnings are printed in both, and preinst dies). I'd really like comments on the guide (that still has to pass through an editor -- Josh would you mind? :) -- so please skip grammar check for now ;) ), so that I can address whatever is needed. Now, I could ask stabilization even right now, but, I'm not sure how to convey enough focus on what is going to happen. I'll write about this on Planet for sure, but then? Is GLEP42 ready? Should I ask PR people to publish this? Anyway, I'll at least give it a week or two for more testing and for proofreading the guide; developers are invited to try the upgrade on their (non-production first) machines, and report immediately any problem with the procedure. Sorry for the delay to get a decent PAM working, thanks for waiting. [1] http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml Diego "Flameeyes" Pettenò http://farragut.flameeyes.is-a-geek.org/ -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 23:04 -0400, Mike Frysinger wrote: > On Wednesday 20 June 2007, Mike Frysinger wrote: > > On Wednesday 20 June 2007, Josh Saddler wrote: > > > Do potential licensing/copyright issues like these factor into your > > > proposal in any way? > > > > no, that's an exercise for the user and no one else ... there's no way i'd > > have the tools prevent this. about the only thing i'd add is a reminder > > message if "binpkg" is in IUSE and not in USE. > > i like this idea so it's been added: > # quickpkg pycrypto > * dev-python/pycrypto-2.0.1-r5: package was emerged with USE=-bindist! > * dev-python/pycrypto-2.0.1-r5: it may not be legal to redistribute this. > * Building package for dev-python/pycrypto-2.0.1-r5 ...[ ok ] > > * Packages now in '/usr/portage/packages': > * dev-python/pycrypto-2.0.1-r5: 188K > -mike Please do the same for qpkg.c tia. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 15:57 -0400, Mike Frysinger wrote:
> On Wednesday 20 June 2007, Marius Mauch wrote:
> > Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > > mayhaps we need a new function to be run in src_install() to label
> > > files as "sensitive" ... so baselayout would do:
> > > esosensitive /etc/{fstab,group,passwd,shadow}
> > > and then we expand the format of CONTENTS in the vdb:
> > > priv /etc/fstab
> >
> > And what would be phase 2 of that? Just having a new filetype
> > in CONTENTS doesn't accomplish anything by itself ...
>
> updating any tool that creates binary packages from the live $ROOT of course
> silly billy
>
> current behavior:
> # quickpkg baselayout
> * Building package for sys-apps/baselayout-1.12.10-r4
> * Packages now in '/usr/portage/pacakges':
> * sys-apps/baselayout-1.12.10-r4: 307K
>
> proposed new behavior (exact output here is not part of the discussion so
> dont
> nit pick it):
> # quickpkg baselayout
> * Building package for sys-apps/baselayout-1.12.10-r4
> * Skipping sensitive file: /etc/passwd
> * Skipping sensitive file: /etc/shadow
> * Skipping sensitive file: /etc/group
> * Packages now in '/usr/portage/pacakges':
> * sys-apps/baselayout-1.12.10-r4: 307K
> # quickpkg --iamsensitive baselayout
> * Building package for sys-apps/baselayout-1.12.10-r4
> * Including sensitive file: /etc/passwd
> * Including sensitive file: /etc/shadow
> * Including sensitive file: /etc/group
> * Packages now in '/usr/portage/pacakges':
> * sys-apps/baselayout-1.12.10-r4: 307K
Suggestion:
If you go down this "sensitive" route. please ensure that the
generated.tbz2 is mode 600 to prevent exposing this sensitive
data more than need be.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: phasing out app-accessibility/festival
On Mon, 2007-06-04 at 23:25 -0500, William Hubbs wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi all, > > app-accessibility/festival has not done a release upstream in some time. Does not look like they have declared it dead however. > We currently have several bugs against this package, including one > security bug. I attached a patch to the security bug for you guys. > Since a lot of blind people are now using espeak as their software > speech synthesizer, and the new version of emacspeak (version 26, which > will be in portage pretty soon) can support espeak, I would like to know > this. > > Once emacspeak 26 is in the tree, I would like to move festival out of > accessibility, or remove it from the tree. One thing to note here is that espeak is only marked stable on amd64 while festival is marked stable on mips ppc amd64 ppc64 sparc ia64 alpha hppa x86. Removing it from the tree does not seem like an ideal alternative any time soon. > If there is a reason to keep festival in the tree, > can someone please contact me and take over the package? I don't want to take it over. But I've used festival and friends often in the past for lazy reading days. I know it's also used supported by asterisk and a few other programs. -- Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye2u Gentoo
On Thu, 2007-05-31 at 11:21 -0700, Ilya A. Volynets-Evenbakh wrote: > Grmbl Can you do us a favor and provide us with a clone, for doing > MIPS keywording? Looks like Kumba has been quite active doing it recently. > Alexander Færøy wrote: > > Hey, > > > > It is my time to leave Gentoo as well. It has been some exciting months > > and I have learned a lot from many of you guys. > > > > It has been interesting to be in one of the major open source projects > > and I have learned a lot from it! > > > > I will move on with some new projects and see if I can become useful there. > > > > I will be around for the Bugday on Saturday and hopefully finish what we > > are missing in that project. Then I'll try to point out a new leader for > > that team. > > > > I am really going to miss a lot of you guys. Especially the ones I met > > during FOSDEM. Hope to see you there next year as well! > > > > Best regards, > > Alex > > > > > -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye Gentoo!
On Thu, 2007-05-31 at 08:47 +0100, Ciaran McCreesh wrote: > On Thu, 31 May 2007 00:05:13 -0700 > Ned Ludd <[EMAIL PROTECTED]> wrote: > > I can understand your frustration and all but I expected and assumed > > you had big balls.. > > It takes more balls to go against the prevailing stagnation than to > just sit by idly and remain content with the situation no matter how > bad it is... perhaps sometimes yes.. None the less I dislike losing core people so quickly who helped out on the back-end to keep things flowing .. He will be missed for sure. -- Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Bye Gentoo!
On Thu, 2007-05-31 at 03:35 +0200, Bryan Østergaard wrote: > It's with a bit of sadness but also a bit of relief that I'm finally > retiring from > Gentoo. > > I've been a Gentoo developer for nearly 4 years now and I like to at least > pretend that I've made some important contributions to Gentoo during that > time. I've had a lot of fun but my frustrations have grown these past several > months and I've been entertaining the idea about retiring from Gentoo for > probably 6 months now. The past couple months the desire to leave Gentoo have > become much stronger and I think it's finally time for me and Gentoo to go our > separate ways. > > I think I've put my "fingerprint" on Gentoo in quite a few important ways but > lately I've come to the realization that I probably can't do any more for > Gentoo. No matter how hard I try fighting for what I feel is right we seem to > end up with petty fights, flamewars or what I consider even worse - people > simply ignore what I'm working hard towards. > > So I think it's high time that I leave the project and start looking for > another project where I can contribute something important and not just try to > keep afloat in a project that I seem to be at odds with to an ever > increasing degree. > > I'll try to reach all the projects I'm leaving over the next few days and see > if I can pass on my work in a reasonable manner. I probably won't be around > much on irc but if you really need to contact me you can do so at > [EMAIL PROTECTED] > > Good luck to all of you and may Gentoo development be as much fun for you as > it used to be for me. > > Best regards, > Bryan Østergaard I'm going to punch you in the ribs really hard if I ever meet you. I count on a few people in this project and you are one of them. I'm really disappointed you are rolling out on us without no for warning. I can understand your frustration and all but I expected and assumed you had big balls.. None the less. I wish you the best in your future endeavors. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Maintainers desired for a few simple pkgs.
I'm looking to get rid of a few ebuilds I half ass maintain. net-wireless/chillispot (Open source captive portal or wireless LAN access point controller) sys-devel/sparse (C semantic parser) Both are relativity low maintenance. Any takers? pretty please with party socks on top. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Planning for automatic assignment of bugs
On Fri, 2007-04-27 at 10:57 -0700, Robin H. Johnson wrote: > On Fri, Apr 27, 2007 at 08:57:27AM -0700, Ned Ludd wrote: > > > In light of the above, how about 'automatic=0'? > > Please keep with your original idea of letting maintainers opt out vs > > some of the ideas proposed in this thread where maintainers have to opt > > in as I'm sure the metadata.xml files wont be updated by enough people > > to really gain the benefit of what we are trying to do here if they have > > to do opt in. > Err, nowhere in here have I said it was going to be opt-in. With some of the dal and tri-state suggestions we have seen in this thread automatic=1/contact=1 this would seem to be an opt-in vs opt-out. But either way I don't care as long as we can get the bulk of the bug-wranglers@ assigned to somewhere other than bug-wranglers@ and the scripts that are going to handle it don't have to become totally convoluted while reasonable to maintain. > Taking into account the other reasonable input, how about the name of > attribute 'automatic-bug' ? I don't see anything wrong with how it was proposed originally using contact=0 > 'automatic-bug=1' will be implied by the DTD, and developers will have > to explicitly opt-out by including 'automatic-bug=0' in their > entries. > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Planning for automatic assignment of bugs
On Thu, 2007-04-26 at 22:01 -0700, Robin H. Johnson wrote: > On Fri, Apr 27, 2007 at 02:33:50AM +0200, Danny van Dyk wrote: > > > Both 'assign' and 'cc' (and derivations thereof are not suitable). > > notification=assignment|cc|none ? > This is to answer expose's question as well, but the attribute should > only indicate if the maintainer entry should be used for any automatic > process at all, not how to use it. > > One of the reasons is that multiple maintainers each with > notification=assignment obviously won't work, and it's non-trivial to > validate via the DTD (yes, DTDs suck compared to XSchema, I know). > > I intend that the first non-excluded maintainer entry is the one used > for the automatic process. > > In terms of implementing this in the DTD, I'm going to specify that > 'contact=1' (or whatever name we settle on) is the default, so that we > don't break validation of any existing metadata: > >contact (0|1) 1 -- should this maintainer be used by > -- automatic processes? > > > > In light of the above, how about 'automatic=0'? Please keep with your original idea of letting maintainers opt out vs some of the ideas proposed in this thread where maintainers have to opt in as I'm sure the metadata.xml files wont be updated by enough people to really gain the benefit of what we are trying to do here if they have to do opt in. Thanks. -- Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Please fix your metadata.xml ASAP
With the loss of our recent bug-wrangler infra will probably be moving to automated system of reassignment of bugs. In order for this to happen you need to properly have your and tags listed in the metadata.xml files. Things such as maintainer "postgresql" are not valid when you are using pgsql-bugs@ for bugzilla. In such cases put pgsql-bugs@ as the maintainer. The maintainer tag must be a valid bugzilla alias or user (domain not required). There are many more cases of this outside of the one listed package. I'll see if I can compile a list of the offenders sometime in the near future. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [ANN] Multiple version suffixes illegal in gentoo-x86
On Tue, 2007-04-24 at 16:00 -0400, Doug Goldstein wrote: > Bryan Østergaard wrote: > > On Tue, Apr 24, 2007 at 03:49:44PM -0400, Doug Goldstein wrote: > > > >> Stephen Bennett wrote: > >> > >>> On Tue, 24 Apr 2007 15:16:38 -0400 > >>> Doug Goldstein <[EMAIL PROTECTED]> wrote: > >>> > >>> > >>> > >>>> So apparently as little as 1 council member can make a decision and it > >>>> be binding unless appealed to the entire council at the next meeting. > >>>> > >>>> > >>> There were three council members who happened to be around at the time, > >>> and those three agreed unanimously. That seems reasonable to me for an > >>> interim decision. > >>> > >>> > >> Is it that serious of an issue that it needed to be done as such and > >> could not wait for a regular council meeting? > >> > >> Granted I understand it's important for you paludis users since paludis > >> doesn't support that. > >> But I'm talking about real Gentoo users that use Portage. > >> > >> I think we are setting a VERY dangerous precedent by allowing a subset > >> of council members to make decisions as a whole if they decide to make a > >> decision outside of a normal session. > >> > >> Who were the 3? > >> > > Already stated in another reply on this thread but the three council > > members were robbat2, kugelfang and myself. > > > > Regards, > > Bryan Østergaard > > > Bryan, > > You and Danny have clearly shown your bias towards paludis take over and > support of Gentoo. It's fairly poor taste to FORCE this through during a > non-regular meeting for something that paludis is lacking. > > It's AMAZING how fast you guys are to clamor and fix what you call a QA > issue and other problems when we've had issues highlighted for years > that the council can't move on. But once it's a possible issue with > paludis you guys are quick to respond. You might be overreacting a little here. To bring you up to speed vapier actually filed the original bug for this after I first noticed one of these atoms creeping into the tree while doing pre release atom compare testing for portage-utils around early February. Till this moment there was no definitive decision of any sort. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-core] Re: [gentoo-dev] Deskzilla license for Gentoo Bugzilla for everyone
Yeah KingTaco pointed that out on IRC. Sorry for any confusion. On Fri, 2007-04-20 at 23:50 +0200, Bjarke Istrup Pedersen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > That was my intention, since it's public for everyone. > - From the email I got it looks like they want me to share it, and spread > the word ;-) > > Bjarke > > Ned Ludd wrote: > > You sent this to -dev vs -core.. Pretty sure they are going to need to > > revoke this license now. > > > > > > > > > > On Fri, 2007-04-20 at 23:05 +0200, Bjarke Istrup Pedersen wrote: > > Hey everyone :-) > > > > Infra told me to go ahead and email this around, so here it is. > > > > Here is a snippet of the email I got: > > > >>>>> Thanks for your request. > >>>>> > >>>>> Please find attached a site license for Gentoo Linux project. Feel > >>>>> free to share the license key with anyone interested or post it on the > >>>>> web. The license allows any number of users, and it is locked to > >>>>> Gentoo Linux Bugzilla URL. If in the future the URL changes, please > >>>>> let me know and I'll create another license key. > >>>>> > >>>>> Please note that this license key requires Deskzilla 1.3 or later. You > >>>>> can download the latest version from > >>>>> http://almworks.com/deskzilla/download.html . > > So there it is. > > For now you can get the ebuild from java-experimental . > > > > Best regards > > Bjarke Istrup Pedersen AKA GurliGebis > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGKTWNO+Ewtpi9rLERAi12AJoC7LspOu85L+GvYedd7KrhyaQwHwCdE9wY > 8VkTaN9fe1jMMG5TRRpOKXU= > =AQbG > -END PGP SIGNATURE- -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Deskzilla license for Gentoo Bugzilla for everyone
You sent this to -dev vs -core.. Pretty sure they are going to need to revoke this license now. On Fri, 2007-04-20 at 23:05 +0200, Bjarke Istrup Pedersen wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hey everyone :-) > > Infra told me to go ahead and email this around, so here it is. > > Here is a snippet of the email I got: > > >>Thanks for your request. > >> > >>Please find attached a site license for Gentoo Linux project. Feel > >>free to share the license key with anyone interested or post it on the > >>web. The license allows any number of users, and it is locked to > >>Gentoo Linux Bugzilla URL. If in the future the URL changes, please > >>let me know and I'll create another license key. > >> > >>Please note that this license key requires Deskzilla 1.3 or later. You > >>can download the latest version from > >>http://almworks.com/deskzilla/download.html . > > So there it is. > For now you can get the ebuild from java-experimental . > > Best regards > Bjarke Istrup Pedersen AKA GurliGebis > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.5 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGKSstO+Ewtpi9rLERAq9AAJ9q1soT6/L9fzJlQ9e7PE2nnNrBSQCeK0gE > TY3o9fnj09fsmbEZut3VZac= > =gPXZ > -END PGP SIGNATURE- -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] $Header:$ and ebuilds
On Fri, 2007-04-20 at 08:22 -0400, Mike Frysinger wrote: > does anyone actually find this useful ? yes quite useful. > i think ive used the value in there > like once (when in reality a `md5sum` would have worked just as well) ... > otherwise, from my perspective: > - it causes annoying bogus hunks in diffs That it does also if the diff is of course in the first few lines. > - not uncommon for people to contact me as the maintainer because i'm in that > - wastes space (well, probably not a strong argument due to bytes vs blocks) > - for mostly green users, it's confusing and they get it wrong > -mike -- Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [POLICY] Keywording/Stabilizing Bug Assignment Policy
On Tue, 2007-04-17 at 14:56 -0400, Doug Goldstein wrote: > I would like to take this time to note and re-affirm the proper bug > assignment policy and have it noted somewhere officially in Gentoo Policy. > > Bugs that are created for the purpose of getting arches to keyword or > stabilize a particular package should initially be assigned to the > herd/maintainer of said package with all requested arches being CCed. > Once all but the last arch has keyworded said package, it is acceptable > and proper for a bug wrangler and/or maintainer/herd to re-assign the > bug to the last remaining arch and they remove that arch from CC. They > should add their herd/maintainer to the CC of the bug. > > Once the last remaining arch has completed the bug, it is up to them to > close it. They know it's up to them to close it since the bug is > assigned directly to them. > > This helps keep bugzilla tidy and makes it easy to identify > stabilization/keywording requests which are a priority for that arch to > take care of. This is in direct conflict with the security bug policy handling which end up putting the maintainer on the CC: along with the arches. Also please don't cross post. -solar -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Removing retired developers from project pages
On Tue, 2007-04-17 at 16:10 +0300, Petteri Räty wrote: > I made a patch to remove all retired developers from the project pages. > If anyone doesn't object I will commit this next week. Feel free to commit any hardened or embedded corrections you have anytime you become aware of them. Thanks. -- Gentoo Linux Ned Ludd <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: extending project xml to have stuff that the project is working on and collect them as Gentoo current goals
On Tue, 2007-04-10 at 23:34 +0300, Petteri Räty wrote: > As the recent thread showed there is a lot going on in Gentoo land > although it doesn't always seem so. I propose we extend project xml to > describe current stuff going on in the project in question and their > estimated completion date. > Then we require this file to be updated > monthly. What do you think? I'd rather not put this stipulation into place. Unless you are proposing that planet.gentoo.org die. Which I don't think you are doing.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] base packages up for grabs
On Mon, 2007-04-09 at 13:36 -0700, Donnie Berkholz wrote: > Mike Frysinger wrote: > > three of those should be a cake walk ... mkinitrd is a friggin mess though, > > so > > after you check the open bugs on it, i dont feel bad if you change your > > mind > > on it > Maybe I will take it over, then decide it's obsolete and send out a > removal notice. =) Please keep it around. embedded users used to find it a handy pkg. initramfs seems to be be winning users over however these days. It (mkinitrd) only ever had 12 bugs ever, 2 of which are currently open and one of those has an attached patch. In reality it should be fairly trivial to maintain. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] *DEVELOPMENT* mail list, right?
On Thu, 2007-04-05 at 19:03 -0400, Michael Cummings wrote: > When you pop into your mail client of choice and find 50+ unread messages in > the > last few hours, you know what kind of day [EMAIL PROTECTED] is having. > > Don't suppose we could get on with that silly topical thing of development? > Surely there's a usenet channel where you can discuss conspiracy.gentoo at > length? Or at least take it to the user list? > > /me stretches and blinks > > So, fellow devs, what's new with development? For those interested, genlop has > migrated into gentoo as a project with the permission of upstream, which no > longer maintain it. Um...any new tools or projects people are working on? > > Anyone? Oh yeah development. Forgot that's what we do.. Here is what I'm doing these days.. Yesterday I pushed a new portage-utils that includes lots of enhancements to the qgrep util (Thanks TGL). With the help of others we are continuing our support of binary packages for lots of profiles (!releng stuff) which can be used for rescue in a pinch or fresh rapid installs as it's nice being able to setup a fully working current desktop in ~45 mins. http://tinderbox.dev.gentoo.org/portage/local/misc/updates.php In due time I'd like to take each of the major profiles and setup 3 build environments for them. One for strictly server (-X -alsa) then another for (+gnome stuff) and another for (+kde stuff) I'm looking for help from c coders to improve the portage-utils(qmerge) applet and package/profile requests from people who would be interested in rapid install methods. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for April
On Thu, 2007-04-05 at 15:20 -0400, Mike Frysinger wrote: > On Sunday 01 April 2007, Mike Frysinger wrote: > > 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. > > another one i had mentioned earlier: > - a time frame on moving gentoo-core to public archives ... two years ? I object and hope this is never done. There are things said on core that I do not wish to be public. I've sent mails myself that if they were ever going to be published publicly I would of never sent them. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 14:03 -0700, Ilya A. Volynets-Evenbakh wrote: > Ned Ludd wrote: > > The correct reply should of been. > > "I'm sorry I did not mean to offend anybody. I'll make an effort to not > > make any cheap shots" > > > Man, stop playing the silly "Ooh, we are all so fragile and offendable > game". Worry about yourself please. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 21:02 +0100, Ciaran McCreesh wrote: > On Thu, 29 Mar 2007 12:25:00 -0700 > Ned Ludd <[EMAIL PROTECTED]> wrote: > > You are being dismissive of the hard work others are doing. I find > > that downright offensive. You want to write a kickass package manager > > then by all means do it. But trying to make yourself look good by > > making others look bad is an underhanded trick. > > This has nothing to do with the people. It's about the code. Not being > able to make changes to a huge mess of spaghetti code doesn't imply any > lack of talent in those who try... > > Please stop looking for excuses for interpreting something as > offensive... The correct reply should of been. "I'm sorry I did not mean to offend anybody. I'll make an effort to not make any cheap shots" -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 20:06 +0100, Ciaran McCreesh wrote: > On Thu, 29 Mar 2007 11:57:36 -0700 > Ned Ludd <[EMAIL PROTECTED]> wrote: > > > Portage or the tree? Portage is just a way of using the tree, and > > > it's not a very good one... > > > > Can you please stop taking cheap pot shots every chance you get. We > > all get it. You are not a fan of portage. > > And that attitude is exactly why Gentoo is no better off than it was > two years ago. You are being dismissive of the hard work others are doing. I find that downright offensive. You want to write a kickass package manager then by all means do it. But trying to make yourself look good by making others look bad is an underhanded trick. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [soc] Python bindings for Paludis
On Thu, 2007-03-29 at 09:56 +0100, Ciaran McCreesh wrote: > On Thu, 29 Mar 2007 01:19:45 +0530 > Anant Narayanan <[EMAIL PROTECTED]> wrote: > > On 28-Mar-07, at 1:45 AM, Ciaran McCreesh wrote: > > > Do you acknowledge that Portage is a severe limiting factor when it > > > comes to improving the Gentoo user experience as a whole? > > > > I certainly don't think so. A lot of people *switch* to Gentoo > > because of portage. Portage is a core part of our distro, and I > > don't see it being replaced for a long time to come. > > Portage or the tree? Portage is just a way of using the tree, and it's > not a very good one... Can you please stop taking cheap pot shots every chance you get. We all get it. You are not a fan of portage. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] get pci info in Linux?
On Thu, 2007-03-29 at 19:55 +0300, Bilanchuk Vitaly wrote: > > Use the library provided by the lspci package, that is what it is there > > for. > > Ok, thanks for you time. > > > What's wrong with using these interfaces? You can use sysfs and proc > > from a C/C++ program just fine... > > sysfs and proc can be unexisting. Chances are you will need to directly communicate with the kernel via a module if proc and sys are not mounted. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed addition to the Social Contract
On Mon, 2007-03-26 at 10:28 -0500, Dale wrote: > Chris Gianelloni wrote: > > On Sun, 2007-03-25 at 22:46 +0100, Christel Dahlskjaer wrote: > > > > > And how exactly does this help us in the event of say the OSL burning > > > down or the GNi suffering flooding? :) > > > > > > > Well, we're on the second floor of the data center which has a quite > > large basement, which would likely absorb most of the water. About the > > only feasible way for our stuff to get flooded is if the San Andreas > > finally gets the "big one" and the west coast of the US falls into the > > Pacific, in which case, we'll be worried about other issues, I'm sure. 3rd floor in C.06 actually. > > That being said, you're more than welcome to assist Infrastructure (and > > the Foundation) in finding new hosting locations as well as the manpower > > to bring new services up in those locations or moving existing services. > > Doing moves like this is a bunch of work, and not something I feel we > > should be "dumping" on the Infrastructure team. > > > > > > Can I assume this building has indoor plumbing? It can be on the top > floor and still get flooded. I saw a house once that the hot water > heater busted and water was about a foot deep and was coming out the > walls. > > More than one way to "flood" a building. :/ Flooding/burning etc are not likely to happen. See page two of the spec for more details. http://www.365main.com/images/365_Main_San_Francisco_CA.pdf -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo infra backups (was: Re: [gentoo-dev] Proposed addition to the Social Contract)
On Mon, 2007-03-26 at 19:44 -0400, Mike Frysinger wrote: > On Monday 26 March 2007, bret curtis wrote: > > Only wimps use tape backup: *real **men* just upload their important > > stuff on *ftp*, and let the rest of the world mirror it. -- LT :1996 > actually, i wonder if this would be useful ... we set up a master backup > server where we post raw svn/cvs/etc... stuff and then allow people to setup > mirrors of it ... Mike, We can't do a full raw mirror. There are restricted things in CVS. A raw copy of the anonymous cvs is about as close as we could do to this. I personally see little to no benefit in the additional overhead in doing that. But if you can make a case to say robbat2 and pylon for why this would be useful to our community then I'm sure we could open up a rsync of the raw anoncvs mirror. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed addition to the Social Contract
On Tue, 2007-03-27 at 00:22 +0200, Paul de Vrieze wrote: > On Monday 26 March 2007, Dale wrote: > > Chris Gianelloni wrote: > > > On Sun, 2007-03-25 at 22:46 +0100, Christel Dahlskjaer wrote: > > >> And how exactly does this help us in the event of say the OSL burning > > >> down or the GNi suffering flooding? :) > > > > > > Well, we're on the second floor of the data center which has a quite > > > large basement, which would likely absorb most of the water. About the > > > only feasible way for our stuff to get flooded is if the San Andreas > > > finally gets the "big one" and the west coast of the US falls into the > > > Pacific, in which case, we'll be worried about other issues, I'm sure. > > > > > > That being said, you're more than welcome to assist Infrastructure (and > > > the Foundation) in finding new hosting locations as well as the manpower > > > to bring new services up in those locations or moving existing services. > > > Doing moves like this is a bunch of work, and not something I feel we > > > should be "dumping" on the Infrastructure team. > > > > Can I assume this building has indoor plumbing? It can be on the top > > floor and still get flooded. I saw a house once that the hot water > > heater busted and water was about a foot deep and was coming out the walls. > > > > More than one way to "flood" a building. :/ > > Actually the situation is not that hypothetical. Some years ago the > datacenter > of the University of Twente (The Netherlands) was set to fire by an angry > systems administrator. The building housed among other infrastructure vital > to the university also some machines of great importance to the debian > project. Due to a combined effort of suppliers, the university staff and the > fact that they had a new datacenter that happened to be about to open, most > things were up an running again in a few days. > The thing I'm worried about > most is insurrance. I trust that infra has backups of the important things > like our repositories. The hosting Gentoo gets from GNi is a world class service in some of the best data centers in the world. Everything important gets backed up nightly from one data center to another. As GNi/365 Main move into more data centers world wide chances are Gentoo will be moving into those additionally as well. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: > On Monday 12 March 2007, Mike Frysinger wrote: > > instead, since we require bash for our ebuilds, use the builtin `type -p` > > err i botched that ;) > > `type -p` is almost a complete drop in replacement for which ... it does not > work on bash builtins however, so people should use `type -P` to force the > PATH search > > in other words, `type -p echo` would return "" while `type -P echo` would > return "/bin/echo" > -mike Here are the remaining offenders for sync 1174037821 that match '$(which ' or '`which ' in eclasses and ebuilds. eclass/mysql.eclass:529: eclass/mysql.eclass:530: app-dicts/stardict/stardict-2.4.8.ebuild:42: sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: www-apps/lxr/lxr-0.3.1.ebuild:37: app-cdr/cdrkit/cdrkit-1.0.ebuild:26: app-cdr/cdrkit/cdrkit-1.0_pre5.ebuild:30: app-cdr/cdrkit/cdrkit-1.1.0.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.1.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.2.ebuild:28: app-dicts/verbiste/verbiste-0.1.16.ebuild:28: app-text/pdftk/pdftk-1.12.ebuild:20: dev-db/hsqldb/hsqldb-1.7.3.1-r1.ebuild:48: dev-util/kdesvn/kdesvn-0.11.1.ebuild:34: dev-util/kdesvn/kdesvn-0.11.1.ebuild:35: media-libs/pdflib/pdflib-5.0.4_p1-r1.ebuild:39: media-libs/pdflib/pdflib-6.0.3-r1.ebuild:48: media-libs/pdflib/pdflib-6.0.3.ebuild:38: sys-process/fcron/fcron-2.0.2.ebuild:28: sys-process/fcron/fcron-2.9.5.1.ebuild:31: sys-process/fcron/fcron-2.9.7.ebuild:26: sys-process/fcron/fcron-3.0.0.ebuild:33: sys-process/fcron/fcron-3.0.1-r1.ebuild:33: sys-process/fcron/fcron-3.0.1.ebuild:33: -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] dont use `which` in ebuilds
On Mon, 2007-03-12 at 19:15 -0400, Mike Frysinger wrote: > On Monday 12 March 2007, Mike Frysinger wrote: > > instead, since we require bash for our ebuilds, use the builtin `type -p` > > err i botched that ;) > > `type -p` is almost a complete drop in replacement for which ... it does not > work on bash builtins however, so people should use `type -P` to force the > PATH search > > in other words, `type -p echo` would return "" while `type -P echo` would > return "/bin/echo" > -mike Quick search shows the following ebuilds are abusing this behavior. Matches "`which " app-dicts/stardict/stardict-2.4.8.ebuild:42: app-emulation/xen-tools/xen-tools-3.0.2-r3.ebuild:57: app-emulation/xen-tools/xen-tools-3.0.2-r4.ebuild:52: media-gfx/quat/quat-1.20.ebuild:26: sci-chemistry/molden/molden-4.3.ebuild:30: sci-libs/blas-atlas/blas-atlas-3.6.0-r1.ebuild:33: sci-libs/blas-atlas/blas-atlas-3.6.0-r2.ebuild:34: sci-libs/blas-atlas/blas-atlas-3.6.0.ebuild:28: sci-libs/lapack-atlas/lapack-atlas-3.6.0.ebuild:64: sci-libs/lapack-reference/lapack-reference-3.0.ebuild:52: sci-mathematics/octave/octave-2.1.57-r1.ebuild:34: sci-mathematics/octave/octave-2.1.69.ebuild:36: www-apps/lxr/lxr-0.3.1.ebuild:37: And matches "$(which " app-cdr/cdrkit/cdrkit-1.0.ebuild:26: app-cdr/cdrkit/cdrkit-1.0_pre5.ebuild:30: app-cdr/cdrkit/cdrkit-1.1.0.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.1.ebuild:28: app-cdr/cdrkit/cdrkit-1.1.2.ebuild:28: app-dicts/verbiste/verbiste-0.1.16.ebuild:28: app-text/pdftk/pdftk-1.12.ebuild:20: dev-db/hsqldb/hsqldb-1.7.3.1-r1.ebuild:48: dev-util/kdesvn/kdesvn-0.11.0.ebuild:34: dev-util/kdesvn/kdesvn-0.11.0.ebuild:35: games-emulation/advancemame/advancemame-0.104.0.ebuild:35: games-emulation/advancemame/advancemame-0.104.0.ebuild:37: games-emulation/advancemame/advancemame-0.104.0.ebuild:39: games-emulation/advancemame/advancemame-0.106.0.ebuild:40: games-emulation/advancemame/advancemame-0.106.0.ebuild:42: games-emulation/advancemame/advancemame-0.106.0.ebuild:44: games-emulation/advancemenu/advancemenu-2.4.13.ebuild:42: games-emulation/advancemenu/advancemenu-2.4.13.ebuild:43: games-emulation/advancemenu/advancemenu-2.4.13.ebuild:44: games-fps/doomsday/doomsday-1.9.0_beta5.ebuild:32: games-fps/quake2-icculus/quake2-icculus-0.16.1-r1.ebuild:72: games-fps/quake2-icculus/quake2-icculus-0.16.1.ebuild:51: games-mud/tkmoo/tkmoo-0.3.32.ebuild:32: games-strategy/boson/boson-0.13.ebuild:43: games-strategy/boson/boson-0.13.ebuild:44: media-libs/pdflib/pdflib-5.0.4_p1-r1.ebuild:39: media-libs/pdflib/pdflib-6.0.3-r1.ebuild:48: media-libs/pdflib/pdflib-6.0.3.ebuild:38: sci-geosciences/grass/grass-6.2.0-r1.ebuild:111: sci-geosciences/mapserver/mapserver-4.10.0.ebuild:106: sci-misc/boinc/boinc-4.72.20050813-r3.ebuild:56: sci-misc/boinc/boinc-5.2.14.ebuild:57: sci-misc/boinc/boinc-5.4.11.ebuild:53: sci-misc/boinc/boinc-5.5.6.ebuild:59: sys-process/fcron/fcron-2.0.2.ebuild:28: sys-process/fcron/fcron-2.9.5.1.ebuild:31: sys-process/fcron/fcron-2.9.7.ebuild:26: sys-process/fcron/fcron-3.0.0.ebuild:33: sys-process/fcron/fcron-3.0.1-r1.ebuild:33: sys-process/fcron/fcron-3.0.1.ebuild:33: x11-misc/xoo/xoo-0.7.ebuild:25: -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] more up to date minimal install cd
On Sat, 2007-03-03 at 02:50 -0500, Chris Gianelloni wrote: [snip] > Remember, we switched from quarterly to bi-annual releases for a reason. FYI. This archived copy was from 2004 http://staff.osuosl.org/~cshields/gentoosurvey/#doc_chap8 We may wish to consider rerunning this survey annually to see where we stand. > We simply didn't have the man power, CPU power, nor time to do vigorous > enough testing in the much more shortened time frame. I'm going to be > asking for Release Testers again once I return, and if last year's turn > out was any indicator (50+ people volunteering, about 5 actually helping > *at all*), the chances of a project such as nightly builds ever taking > off is well beyond our means at this time. > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thu, 2007-02-08 at 14:49 -0700, Daniel Robbins wrote: > On 2/8/07, Ned Ludd <[EMAIL PROTECTED]> wrote: > > As somebody that's had to hand write many of those kinds of scripts. A > > single rcS is not very ideal. Our init scripts are in fact mostly usable > > by busybox. Granted there are a few special special cases, but then Roy > > is offering to update those for free. One of the larger problems really > > boils down to many packages provide default init.d scripts and these > > expect the existing baselayout only. That will be a bigger feat to deal > > with later on down the road. > > Developers will then need to test their init.d scripts to ensure that > they are compatible with busybox. This is asking a lot of work of > people just so you can use Gentoo's initscripts for something they are > not really ideal for. I don't think anybody can/would expect that. They don't test for hardened or uClibc now before stabilizing a pkg. What would be nice to see is if a maintainer is offered a posix compliant init.d script that they merge it or allow those to be merged for a pkg they maintain as long as it does not degrade functionality. > Any time a script is updated a new rev of a > package is required, and this does impact users and will cause > packages to be rebuilt when a user does "emerge -u". So I think this > should be weighed against the potential benefits of baselayout + > busybox. busybox is not Roys underlying goal as far as I understand. I think he simply mentioned it as an example of another group who wishes to unify efforts and have an interest in getting away from arrays where feasible. > If you are targetting something smaller than 32MB, then maybe busybox > is appropriate. But you are trying to go really small, then you > probably don't want all the extra junk in our initscripts. And if you > are _not_ trying to go really small, then put bash in your filesystem, > not busybox, and the initscripts will work. If bash isn't fast enough > from a boot time perspective, then the gentoo initscripts certainly > aren't going to be fast enough either. > > In other words: > > busybox + single rcS file = fastest and simplest, smallest, best for > very small filesystems, not as flexible > > bash + gentoo baselayout = most flexible, biggest, slower, best for > feature-rich systems > > busybox + gentoo baselayout = ? It's been done in the past by end users. Before there were only about 4 changes needed to make it work. That all changed when bash arrays were introduced. > I think that in 99 out of 100 cases, if you have room for baselayout, > then you probably have room for bash too. And in 99 out of 100 cases, > if you can deal with the load time of baselayout, then you can deal > with the overhead that might be incurred from having bash. > > I'm just pointing out that it's not an obviously good combination. In > the grand scheme of things, maybe it's not a great use of developer > resources. Or, maybe I'm wrong and it is a great idea. His time and resources. His "itch" > Personally I think that "baselayout + busybox" may be cool, but adding > an aftermarket sunroof to your car can be cool too. But that doesn't > mean it's worth the effort :) I don't think those who are not interested in this will be burden by any extra effort. Worst case is maybe getting a bug assigned to you which offers a posix replacement/update for the default init.d a pkg you maintain might provide. > Really, it's hard for me to imagine many scenarios where you really > need the flexibility of baselayout but can't squeeze in bash. And I > have a pretty good imagination. baselayout is only about a half of a meg these days and probably getting smaller/faster with the addition of the multicall rc/runscript work he has been doing. Adding bash also requires ncurses which in turn mostly requires having a c++ aware compiler or using the nocxx,minimal flags. Even with those flags enabled I'm seeing 3M going to ncurses+bash. So I can for sure see the benefits. Also for a moment lets stop and think. Some XYZ update breaks ncurses/bash. Supporting this gives us a nice alternative way to still boot our boxes for rescue using ash or another shell which might not have such big deps. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Thu, 2007-02-08 at 13:23 -0700, Daniel Robbins wrote: > I sort of missed this conversation, so apologies in advance if this > has already been covered, but wanted to say that gentoo's initscripts > are generally not suited for embedded systems. > > So making baselayout busybox-compatible doesn't seem to be worth the > disruption and headaches it would cause. Please read over what's been talked about elsewhere in this thread. He is not trying to break existing functionality at all. Only extend it to be posix aware (additionally) > It would be disruptive for > gentoo developers who would need to be extra-careful in maintaining > their initscripts to ensure busybox compatibility. Not to mention the > potential disruption for users. There is no reason this has to be disruptive to the users who don't care about this functionality. > If you are building an embedded system using busybox, then generally > you will want a single /etc/init.d/rcS script that starts all the > stuff you need. As somebody that's had to hand write many of those kinds of scripts. A single rcS is not very ideal. Our init scripts are in fact mostly usable by busybox. Granted there are a few special special cases, but then Roy is offering to update those for free. One of the larger problems really boils down to many packages provide default init.d scripts and these expect the existing baselayout only. That will be a bigger feat to deal with later on down the road. > -Daniel > > On 2/8/07, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Thursday 08 February 2007, Roy Marples wrote: > > > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > > > On Wednesday 07 February 2007, Roy Marples wrote: > > > > > In the current code I'm running it's only the network stuff that > > > > > uses arrays. If you're thinking about /sbin/functions.sh, well that > > > > > can stay as bash as it's not used by baselayout anymore. > > > > > > > > some init.d scripts use arrays as well > > > > > > Do we know which ones? > > > > grep for it :p > > netmount for sure right now > > > > > The actual scripts themselves can be re-worked if they need to be - > > > this problem only when the arrays are used in config files. > > > > i guess my point was i think we really need to be consistent here ... either > > arrays are OK for init.d scripts or they're not OK > > > > did you get a chance to see how hard it would be to integrate the bash array > > code ? > > -mike > > > > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New network config for baselayout-ng
On Wed, 2007-02-07 at 13:16 +, Roy Marples wrote:
> OK, so everyone wants to keep their conf.d/net in bash. Fine by me.
>
> Welcome to baselayout-ng which will be a virtual and will not require
> bash.
Good. Maybe now we can get rid of the pretty much non functional
baselayout-lite which basically only every provided an /etc/inittab and
made a few device nods.
> Now that's out of the way, let's discuss configuration :)
>
> We still need something that is "array like" for want of a better
> phrase, so how about delimiting using ; like so
> config_eth0="10.1.1.1 netmask 255.255.255.0; 10.1.1.2/24"
The ; seems logical.
>
> You could even use bash expansion here, provided that bash is your shell
> config_eth0="10.1.1.{1..30}/8; 192.168.0.1 netmask 255.255.255.0"
>
> See, that's not too bad is it?
Nope.
> Thanks
>
> Roy
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Network configuration and bash
On Tue, 2007-02-06 at 19:42 -0500, Mike Frysinger wrote:
> On Tuesday 06 February 2007, Kevin F. Quinn wrote:
> > You need to define what shell (or subset) you want to parse it. 'sh'
> > itself varies from platform to platform.
>
> our standard has always ("always" is relative here; let's say "current") been
> the bash superset of POSIX ... if a request comes up where someone wants to
> change code because it breaks in their shell but the code in question is
> POSIX compliant, the answer is simple: blow me
>
> if the request is reasonable like stop using some bashism in favor of the
> POSIX form and the change isnt invasive, then sure we'll generally make the
> change
/me likes the direction Roy is heading with this.
> -mike
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: eclass proposal - savedconfig.eclass
On Fri, 2007-02-02 at 04:08 +, Duncan wrote: > Thomas Rösner <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Thu, 01 Feb 2007 > 20:46:41 +0100: > > > sys-kernel/*? Or perhaps genkernel? Being able to build kernel images just > > like any other package in Gentoo would be nice. > > But with make oldconfig, so the user gets asked about new options, and > those get saved back to the savedconfig, right? No way.. Please see how we handle this in busybox.ebuild which is the best documented example of the savedconfig option in the tree. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Topic for Feb council meeting
On Mon, 2007-01-29 at 14:46 +, Roy Marples wrote: > On Mon, 29 Jan 2007 13:39:05 +0100 > "Rob C" <[EMAIL PROTECTED]> wrote: > > > For what its worth, I think option #2 is the best. > > > > I think option #1 is out of the question and I think that #3 is flawed > > because the 8th spot developer's situation or commitment to the > > project may have changed since the last vote and in any case that > > developer would be free to partake in the running vote with #2. > > > > Cheers > > -Rob > > Then it should be offered to the 8th person, at which point either > he/she will then refuse the nomination and it's offered to the 9th. > Rinse and repeat. > If we run out of nominees then we'll need another election. > Agreed. #3 >From my POV having a new election potentially over and over is a waste of time and resources. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: ecompress heads up
On Fri, 2007-01-26 at 19:56 -0600, Ryan Hill wrote: > Mike Frysinger wrote: > > On Friday 26 January 2007 17:19, Mike Frysinger wrote: > >> i purposefully choose to not go this route because i dont want to start > >> adding handling for arbitrary compression types ... when such a list > >> exists, we always get people who want use to add support for their > >> $favorite-compression > > > > that said, i would entertain the notion of auto uncompressing > > just .bz2, .gz, .Z and telling everyone else to toss off ... > > What about .zip? Not apart of the base-system. > > *runs away* > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GIT vs? SVN (was: Re: Re: [RFC] Some sync control)
On Thu, 2007-01-25 at 23:37 +0100, Markus Ullmann wrote: > So to avoid thread hijacking, starting a new one. What exactly is this thread you are starting about? Just letting us know you did some random testing? > > I did some tests today and took sunrise overlay as testing ground. > It has roughly 2850 revisions. As a blog recommended, I fetched the raw > repo first to do the initial conversion to git. > > Then all I did was a > git-svn init file:///home/jokey/sunrise-svn && git-svn fetch > It took 5 minutes and 12 secs for me on a not-so fast box. Then I had a > git repo that could do all the branching, file merging and stuff and it > sends it back to repo nicely. Even a reversion of a commit worked perfectly. > > git log gave this output: > commit a8c35b8efe130fca7e2c3bb0d589a2d251f381c3 > Author: ndansmith <[EMAIL PROTECTED]> > Date: Thu Jan 25 03:35:02 2007 + > > Removing old turl files in favor of surl > > git-svn-id: file:///home/jokey/test/[EMAIL PROTECTED] > 12608f7e-a915-0410-b2f3-ce240db1b126 > > So judging from this, I'd say we could use advantages of both. Those who > wish git can go for it (the git repo, as pointed out on this list, can > initially be fetched via rsync or tarballs or whatever comes in handy) > and those who dislike git can just go with svn and be happy with it. > > Jokey > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote: > On 1/11/07, Marius Mauch <[EMAIL PROTECTED]> wrote: > > > And I assume there is a non-trivial number of custom scripts out there > > using make.profile, but that's nothing we can do about. > > > > You could give them all a grace period for which have to comply with > the new standard by then end of it, and have ( during that grace > period ) an automatic symlink generation based on that make.conf flag. > > And just to make sure, I doubt it would be too difficult to have an > application that analyises packages as they install to check whether > they reference make.profile or not, and flag a QA warning if they do. > > And packages that don't switch to the standard by the end of the grace > period I guess we'll see on a "last rites" bulletin ;) Or we/gentoo could just support it and stop breaking the end user. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] deprecating /etc/make.profile
On Wed, 2007-01-10 at 16:30 +0200, Simon Stelling wrote: > Hi all, > > As per bug 148388 [1] comment 1, I'd like to discuss the deprecation of > /etc/make.profile and the use of a PORTAGE_PROFILE variable instead. > Reason for this change aside from consistency with all other portage > settings is the annoyance of re-adjusting the /etc/make.profile link > before and after testing a profile change in an overlay/development repo. PORTAGE_CONFIGROOT= kinda solves your problem. But I do admit it would be a lot easier dealing with a variable vs having to parse the symlink to figure out the profile. If this change does happen I'd suggest that we support make.profile symlinks as long as they exist unless the make.conf defines the variable. If variable exists it should override. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentle reminder about ChangeLog entries on profiles
On Mon, 2007-01-08 at 17:40 -0500, Chris Gianelloni wrote: > On Mon, 2007-01-08 at 12:20 -0800, Robin H. Johnson wrote: > > On Mon, Jan 08, 2007 at 08:27:50AM -0500, Chris Gianelloni wrote: > > > Most of the profiles under default-linux have a ChangeLog at the > > > architecture level. If you make *any* changes to a profile, you should > > > be putting your changes in the ChangeLog. > > > Just wondering, any objections if we add ChangeLogs at the rest of the > > levels in profiles? Would esp. be useful for some of the more global > > changes. > > Not really. > > Personally, I'd prefer there not be ChangeLogs any deeper on > default-linux than $arch, so adding one to, say, default-linux would be > good, adding one to default-linux/x86/2006.1 would be rather pointless. > I could definitely see the use of having one on base and default-linux, > for sure. > I'll leave it up to other projects (hardened/embedded/etc) if > they would want to follow suit, but it definitely makes Release > Engineering work much easier having it. No objections. TBH we don't really have to edit those profiles often. We/I try to keep them as static as possible. When they do change it's usually cuz somebody has some brilliant idea for some non linux which forces all other profiles to update to mask or unmask some use flag. We/I tend to request that they update it themselves. But note taken. If I have to edit something I'll try to remember to add a ChangeLog entry. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: PORTAGE_BINHOST Madness
On Sun, 2007-01-07 at 05:16 +, Steve Long wrote: > Alec Warner wrote: > > Talk to solar about binhost, I know he has a better implementation lying > > around; it's a matter of finalizing it ;) > solar: where is it on your site? Tip: If you want me to respond to something that directed to me it's best to CC: me directly as it's easy to miss threads on high volume lists. I use the qmerge applet from portage-utils to grab the pkgs to the localhost then emerge -Kpv $pkg. So on a fresh install I do something like wget hardened-tarball.tbz2 unpack emerge portage-utils set binhost qmerge -f $(qlist -IC) emerge -C pam-login emerge -Ke system otherwise I just qmerge -f $pkg ; emerge -Kpv $pkg The qmerge applet requires the use of the genpkgindex util on the remote bin repo. I know pkgcore is going to start using this same format for it's remote bin repo stuff. I talked with Zac (zmedico) last week about portage supporting it also. I think he is keen on it but the tool will need love on solving the $PN conflicts. Between us 3 we will come up with a standard sooner or later. (probably later vs sooner) http://sources.gentoo.org/viewcvs.py/*checkout*/gentoolkit/trunk/src/genpkgindex/genpkgindex it generates output like the following. http://tinderbox.dev.gentoo.org/hardened/x86/Packages -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Portage feature addition
On Tue, 2006-12-05 at 08:58 +, Steve Long wrote: > Ned Ludd wrote: > > > > > cd $(portageq envvar PORTDIR)/virtual/ > > mkdir mike > > cd mike > > echo 'echo OWNED at phase $EBUILD_PHASE' > mike-0.0.ebuild > > emerge -pv mike > > > Just checking; commands run there are run as root, right? Most often yes they would be preformed as the root user, unless the user of portage is in the portage group and has write access to the tree. > Are they run in a chroot jail? umm nope. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage feature addition
On Sun, 2006-12-03 at 14:33 -0500, Mike Frysinger wrote: > On Sunday 03 December 2006 01:00, Alec Warner wrote: > > Recently commited to svn (but afaik released only in ~arch) is code to > > prevent the sourcing of ebuilds with no manifest. Thus ebuilds you > > randomly download off of bugzilla need to get a lookover from you and > > then ebuild foo.ebuild digest'd. > > i thought portage always did that ... if you have FEATURES=strict, it'll > complain that a file doesnt exist in the Manifest and abort Nope.. Try this.. cd $(portageq envvar PORTDIR)/virtual/ mkdir mike cd mike echo 'echo OWNED at phase $EBUILD_PHASE' > mike-0.0.ebuild emerge -pv mike > -mike -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Sat, 2006-08-12 at 17:17 +0200, Harald van Dijk wrote: > On Sat, Aug 12, 2006 at 02:42:32PM +, Francesco Riosa wrote: > > [...] > > >> > > >> $ cd gentoo-x86/*/foo > > > > > > This works better: > > > > > > $ cd gentoo-x86/*/foo/ > > > > > > This avoids the case where a file by the same name exists (for > > > example, in licenses/). > > > > may be > > $ cd gentoo-x86/*-*/foo/ > > ? > > Maybe. That avoids virtual/*, which may or may not be a good thing, > depending on your needs. (The only other case where it helps is > uclibc, which is probably already a special enough case that it can > be mostly ignored for this thread.) /me lands in the profiles dir when he really wants the *-* dir all the time. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 2006-08-05 at 16:07 -0400, Stephen P. Becker wrote: > Mike Frysinger wrote: > > On Saturday 05 August 2006 14:56, Stephen P. Becker wrote: > >> The metadata for sandbox suggests that it is under the control of the > >> portage team, even if they lack a herd: > > > > ... because it is tightly integrated with portage ... there is the aspects > > of > > portage which require some sandbox env setup/etc..., then there is sandbox > > itself > > > > but seriously, you've been around forever, you know this :p > > Of course I know this, and it sucks. If sandbox is so tightly > integrated with portage, then why *isn't* there a portage team member > who works on sandbox? cuz portage is a python beast and azarah wrote sandbox in c as a preload module. And really as Mike already pointed out the problem lies within the mips dynamic linker/loader.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Make FEATURES=test the default
On Sat, 2006-08-05 at 12:57 +0200, Kevin F. Quinn wrote: > On Sat, 5 Aug 2006 11:49:53 +0200 > Danny van Dyk <[EMAIL PROTECTED]> wrote: > > > Please re-read the list of packages that fail tests: > > * glibc > > * autoconf > > * gettext > > * tar > > That makes _4_ system packages. Before I would consider making > > FEATURES=test a default, I would add least want the system set to > > actually merge with it. > > So you're happy to let users install these packages without them > knowing the tests would fail? > > I certainly agree they should pass their tests. autoconf-2.60, > gettext-0.15 and tar-1.15.1-r1, which are the latest versions I > have installed here, all pass on my system. If they fail on your > platform, then you should make sure bugs are open and the relevant > maintainers are doing something about it, and IMO they should not go to > arch (i.e. should remain ~arch) until the test issues are resolved. > > Thing is, at the moment you have a bunch of packages installed that > fail their tests. This may mean the tests are broken, however it may > also mean the packages are not working correctly on your system, and > I'd be concerned if I were you. With some arches this is not really an option. Also system pkgs such like the toolchain need to have additional deps. > Avoiding the test phase doesn't make > the packages work, obviously. > > glibc is somewhat of a special case; it is especially sensitive to > the environment - many of the tests assume a vanilla RedHat > environment, and often the test failures in glibc are not actual > problems with glibc but limitations of the test suite. Sometimes the tests are flat out wrong. Take for example say we decided to paxtest ran itself in as the test.. This would surely fail on amd64 as one or two of the tests assume page sizes of 4096. > However we > should not be encouraging people to install glibc versions where the > test failures are not understood. The alternative would then become for the end user to use another distro with less hassles. We would surely get the rep of sucking if nobody could even install libc. > Clearly if something in glibc is not > behaving properly, the effects can be nasty. Which for the most part is why features like this should be opt-in vs opt-out or be left up to the $ARCH teams. A lot of people are opting in so most of these will be fixed in due time.. The $ARCH teams *should* already be setting this feature for the most part before stable markings. It's a noble idea. I just don't think we are ready for FEATURES=test && USE=test either. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Thu, 2006-08-03 at 16:07 +0200, Jakub Moc wrote: > Ned Ludd wrote: > > On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote: > >>>> Would like the Council to discuss the current state of Gentoo Bugzilla > >>>> [1] and anon CVS/SVN [2]. > >>> Please elaborate why you need the council to discuss > >>> ongoing active bugs that are in progress. > > Progress? Erm... see below. > > >> I would also like to know why the council has to be involved since > >> you've never sent an email to infra specifically asking the same thing > >> first. Sure makes sense to me that you should ask the group involved > >> with the work first instead of going to the top. > > Because it's been broken for ages? Because I've asked the same on the > bug I've referred to multiple times, as did quite a few other people, > and the thing is still dead ~3 hours a day? (So uhm, the argument that > infra doesn't know about is _really_ moot.) Because users complain over > and over again? Because we are getting tons of duplicate bugs due to > bugzilla being non-responsive? Ok this is basically bitching. Trust me we all know the current state of things with bugzilla and it's not fun for anybody. I'm sure however if you practice a little patience I'm sure you will be quite pleased with the end result. > Because it's wasting hours of my time > every day? Because if CVS was in the same state, you'd about have a > revolution by now? I think you might be misunderstanding the role that the council plays. It's a body for technical matters that effect the mainly "the code". Daily matters of infrastructure are handled by our infra team naturally. Funding for hardware is approved by the foundation. > >> The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn > >> guru. We want to ensure that we cover all our grounds in the setup so > >> that we don't make a system that's easily DoS'able. If anyone wants to > >> help out with that, please contact KingTaco as he's the contact for that > >> project right now. > > > > It's just about ready afaik. We just want robbat2 to review the CVS > > setup and I probably need to drop a patch in the cvs pkg to disable > > compression. We probably also want Pylon to review the svn setup. > > Good news, would be nice if you actually responded on the bug maybe? Or > send out some status report occasionally, since the bug's been open for > ~1 year now? > > >> Patience is indeed a virtue. > > > > Indeed.. > > Sorry, having a critical facility broken for ~6 months right now =! > patience. It plain sucks. You must live in that town where spare hardware and administrators grow on the trees. As it stands I do not see why this needs to be an agenda item for council discussions. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Thu, 2006-08-03 at 08:06 -0500, Lance Albertson wrote: > Ned Ludd wrote: > > On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote: > >> Mike Frysinger wrote: > >>> This is your monthly friendly reminder ! Same bat time (typically the > >>> 2nd Thursday once a month), same bat channel (#gentoo-council @ > >>> irc.freenode.net) ! > >> Would like the Council to discuss the current state of Gentoo Bugzilla > >> [1] and anon CVS/SVN [2]. > > > > Please elaborate why you need the council to discuss > > ongoing active bugs that are in progress. > > > > I would also like to know why the council has to be involved since > you've never sent an email to infra specifically asking the same thing > first. Sure makes sense to me that you should ask the group involved > with the work first instead of going to the top. > > But since I'm typing it now, I might as well answer it. > > I finally got the hardware this week for bugs, and I've been working on > bringing those boxes online. And it's impressive hardware at a pretty kickass facility :) > If I'm lucky, I'll have them at least > booting on their own today. > > The anoncvs/svn stuff needs the attention of some knowledgeable cvs/svn > guru. We want to ensure that we cover all our grounds in the setup so > that we don't make a system that's easily DoS'able. If anyone wants to > help out with that, please contact KingTaco as he's the contact for that > project right now. It's just about ready afaik. We just want robbat2 to review the CVS setup and I probably need to drop a patch in the cvs pkg to disable compression. We probably also want Pylon to review the svn setup. > Patience is indeed a virtue. Indeed.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for August
On Thu, 2006-08-03 at 11:21 +0200, Jakub Moc wrote: > Mike Frysinger wrote: > > This is your monthly friendly reminder ! Same bat time (typically the > > 2nd Thursday once a month), same bat channel (#gentoo-council @ > > irc.freenode.net) ! > > Would like the Council to discuss the current state of Gentoo Bugzilla > [1] and anon CVS/SVN [2]. Please elaborate why you need the council to discuss ongoing active bugs that are in progress. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 2006-08-01 at 00:29 +0200, Alexandre Buisse wrote: > On Mon, Jul 31, 2006 at 23:14:56 +0200, Ned Ludd wrote: > > -- No -- > > nattfodd (nfc) ... > clue"? I might agree to both :) Meaning only that we have not really worked together. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, 2006-07-31 at 21:39 +, Bryan Ãstergaard wrote: > On Mon, Jul 31, 2006 at 04:48:42PM -0400, Ned Ludd wrote: > > kloeri (nice guy but dunno if the council is a proper match) > Guess I could do a lot worse than "nice guy" :) I haven't been part of > the council before so it's a bit difficult saying if it's a good fit or > not. But I'd certainly do my best to improve Gentoo if I'm elected. I can change that text to read.. (pretty kick ass guy but still dunno) > I think just about everybody knows my work by now and know that I care > deeply about Gentoo. Who knows, maybe I care too much? Or care about the > wrong things? I've seen and dealt with you mostly on new recruits and people retiring.. Bit of devrel stuff.. More people oriented vs technical work. I know you also work on the alpha's but that seems more bump here bump there kinda of work. You are around a lot (which is key), and you are pretty personable. Still I have mixed feelings. I think perhaps you would make a kick ass trustee. > Fortunately, that's up to the general developer community > to decide just as it should be. > > Let's hope we get the best possible council and that we'll continue to > see Gentoo improving. Agreed.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, 2006-07-31 at 23:30 +0200, Lars Weiler wrote: > * Ned Ludd <[EMAIL PROTECTED]> [06/07/31 16:48 -0400]: > > Pylon (maybe.. not around enough however) > > I don't know the basis for your statement, but I'm quite > good around. > > Is it that you don't see that many emails from me here at > this list? Or is it that you don't see me hanging out in > #gentoo-dev all the day? Neither actually. It's cuz I don't bump into you in that many channels. When I don't bump into people very often it's hard to think that they are around and will have a clear picture of whats going on in gentoo world outside of what we usually see on the lists. > Keep in mind, that Gentoo is a quite large project. Usually > I hide in the PowerPC department or in it's subsidiary for > release engineering (the coffee over there is better!). CVS > and SVN are both working, so that I don't have to go out for > lunch with the infra-team. But in the evenings I join the > German community and keep an ear on their demands. I'm one of those damned Americans. Perhaps that's why our paths don't cross that much outside of infra. None the less you are defiantly somebody I respect and I wish you the best of luck. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Mon, 2006-07-31 at 14:00 -0700, Daniel Ostrow wrote: > > > Some notes on some of the other people from my POV.. > > > > -- Busy/Next Year/Other -- > > dostrow (not around enough) > > > I'd agree that my availability over the past 6 months has been spotty at > best. I was ramping up for a cross country move and all that that > entails as well as dealing with a new position at work which was keeping > me more busy then I thought I could have been. While I'm willing to > state that I will be around more from here on out as I'm done moving and > have settled into the routine that my job requires I believe that my > prior record of availability (as it is all you have to go by) should > certainly be taken into account. Thanks for bringing this point up > solar. I'd still like to be considered as I believe I have a lot to > offer but when you all are voting it should be something you are > thinking about. Thanks for clarifying. I wish you the best of luck then. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tue, 2006-07-04 at 15:04 -0400, Mike Frysinger wrote: > On Saturday 01 July 2006 02:46, Mike Frysinger wrote: > > well it's about that time of the year ... time for nominating > > people for the next Gentoo Council > > i guess i'll start off some mass nominations of random people off the top of > my head who i think would do a good job ... there's a bunch more people i > think would do a good job, but i'm going to cut my list short as it's already > ridiculously long ... > > from current council: > koon / agriffis / azarah / seemant / solar Thanks mike but I'm still undecided. A part of me wants to say no to a year long commitment yet another part of me wants to take it on. I for sure wanted to put this off till the last possible moment as I have to tend to a few things in my personal life. Some notes on some of the other people from my POV.. -- Busy/Next Year/Other -- dostrow (not around enough) Flameeyes (nice guy but talks to much, maybe next year) kloeri (nice guy but dunno if the council is a proper match) Pylon (maybe.. not around enough however) -- Maybe Yes -- Kugelfang (amd64/other?) wolf31o2 (releng/future trustee) -- Yes -- vapier (global) KingTaco (infra/amd64) lu_zero (senior dev/ppc) jaervosz (sec dev) ramereth (infra) robbat2 (gpg signing/CGL) -- No -- nattfodd (nfc) patrick (nope) pauldv (probably not/new dad) spb (really bad idea) -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Wed, 2006-07-19 at 17:10 +0100, Ciaran McCreesh wrote: > On Wed, 19 Jul 2006 11:10:51 -0400 Ned Ludd <[EMAIL PROTECTED]> wrote: > | Every single year quarter after quarter the more updates > | that happen the slower portage is becoming. > | Care to solve that? > > This is a minute amount of time in comparison to anything significant. > If you care about Portage speed, you'd be far better off reducing the > number of packages that users have installed and reducing the number of > packages in the tree. > > | My fix would be to remove the ability to do package moves > | from portage all together. > > Which makes me rather glad that you're not fixing anything... > > | > | > i dont think this sort of thing should hold up tree > | > shuffles ... > | > | Well it should. > | > | package.keywords package.use package.mask etc.. > | > | Where is the stability and consistency when we end up > | forcing people to update /etc/portage files... > > Erm... Portage updates these automatically. as .cfg_** files. The end user still has to run an etc-update and pray that it was not a file he/she had in masking. None the less I think you missed the part in the tread along time ago which Stefan said he would do the moves at the same time as bumps. Doing it that way solves most of the problems. Granted not all of them like the vdb/*DEPEND entries of other pkgs. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: New category: net-voip
On Tue, 2006-07-18 at 15:51 +0200, Stefan Schweizer wrote: > Ned Ludd wrote: > > Creation of a new categories is fine. pkg moves are bad. > > See the countless other posting on this subject of why pkg > > moves are bad. > yeah new packages is my primary concern. > > >> Any objections, problems with the plan, comments? > > > > Sure I'll step up and say I object to the part of your plan which > > involves a shitton of pkgmoves. Moving pkgs from existing categories > > into another category causes numerous problems that portage can't solve > > as easy as the rest of us might think so please just don't do that > > part. I've got no objection to the creation of a new category for *new* > > packages. > > I talked with you in IRC about this more. We will do the package moves only > when a bump occurs and will make sure that stable as well as ~arch get an > updated ebuild. Sweet/Thanks that works and provides a clear path to upgrade/bump. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 2006-07-18 at 15:15 +0100, Ciaran McCreesh wrote: > On Tue, 18 Jul 2006 09:34:37 -0400 Ned Ludd <[EMAIL PROTECTED]> wrote: > | Creation of a new categories is fine. pkg moves are bad. > | See the countless other posting on this subject of why pkg > | moves are bad. > > Uh, as far as I recall, you've yet to come up with any technical > explanation other than "it breaks one of my pet projects"... The gains > of consistency and manageability far outweigh the minor inconvenience. There is no consistency for end users when stuff keeps getting shuffled around. Portage still can't get it right. 'fixpackages' does not correct the installed vdb content so the problems extend past any of my pet projects. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New category: net-voip
On Tue, 2006-07-18 at 14:53 +0200, Stefan Schweizer wrote: > Hi, > > the herd of voip packages is constantly growing and according to > "herdstat -p voip" we already have 60 packages in the voip herd. Those are > currently in the categories net-misc, net-im, net-libs, dev-libs and > media-libs. Most of them would fit perfectly into a new net-voip category. > Those are enough packages to allow the creation of a new category. > > More important than the current packages I think it is to put new packages > into the more precise net-voip instead of net-misc/net-im. For example some > packages in my overlay [1] maintained by the fellow gentoo users peper and > fuoco. Also there is a lot of stuff waiting in stkn's private voip overlay > > The 47 voip packages in net-misc and net-im should be moved over to the new > category definitely, you can get the list with: > herdstat -p voip | grep -e net-im -e net-misc > From the others I think dev-libs/ilbc-rfc3951 should be moved, too. Creation of a new categories is fine. pkg moves are bad. See the countless other posting on this subject of why pkg moves are bad. > Any objections, problems with the plan, comments? Sure I'll step up and say I object to the part of your plan which involves a shitton of pkgmoves. Moving pkgs from existing categories into another category causes numerous problems that portage can't solve as easy as the rest of us might think so please just don't do that part. I've got no objection to the creation of a new category for *new* packages. > > > [1] http://overlays.gentoo.org/svn/dev/genstef/net-im > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Sat, 2006-07-15 at 13:41 -0400, Ned Ludd wrote: > On Sat, 2006-07-15 at 17:45 +0100, Daniel Drake wrote: > > Hi, > > > > The local root exploit-of-the-week would have been unable to run if our > > users systems had /proc mounted with nosuid and/or noexec > > > > It would be worthwhile considering making this a default. What are > > people's thoughts? > > I mailed Mike about this very thing a month ago. Pretty sure it should > be showing up in an upcoming baselayout. But yeah it's a good idea for > the nosuid part anyway. Not 100% sure about the noexec part as that > might break upx which calls /proc/self/exe as part of it's decompresser > routines. Tested it using a and it seems safe across the board. upx,busybox and other multicall binaries seem quite content. Linus also recently suggested that the same be done in the kernel directly via the proc_fill_super() function. This seems like an ideal route to go for us as it would get inherited by all the existing users who wont notice the change in the default fstab file. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making procfs mount as nosuid,noexec by default
On Sat, 2006-07-15 at 17:45 +0100, Daniel Drake wrote: > Hi, > > The local root exploit-of-the-week would have been unable to run if our > users systems had /proc mounted with nosuid and/or noexec > > It would be worthwhile considering making this a default. What are > people's thoughts? I mailed Mike about this very thing a month ago. Pretty sure it should be showing up in an upcoming baselayout. But yeah it's a good idea for the nosuid part anyway. Not 100% sure about the noexec part as that might break upx which calls /proc/self/exe as part of it's decompresser routines. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Dying on some CFLAGS instead of filtering them.
On Mon, 2006-07-10 at 01:34 -0700, Richard Fish wrote: > On 7/9/06, Denis Dupeyron <[EMAIL PROTECTED]> wrote: > > 2) If yes, are there any other flags that ebuilds should die on ? > > My (user) opinion is that ebuilds should not die on CFLAGS, at least > not until per-package CFLAGS are implemented. per pkg cflags are here already it would fall under the per pkg env variables. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 23:09 +0200, Harald van Dijk wrote: > On Fri, Jul 07, 2006 at 03:57:51PM -0400, Ned Ludd wrote: > > On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: > > > On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: > > > > Keep pushing this and the only thing you will end up with is the > > > > vanilla flag being removed all together.. > > > > > > Is that a threat? If not, is there a reason behind this? > > > > Yes.. When users or devs complain non stop when they > > don't understand something it leaves us with a few choices. > > 1) put up with people not having a clue. > > 2) remove the option so they can't bitch about it. > > > > Option #1 is not fun as it pushes the hand on #2 > > Option 3: Enlighten me. I have explained why I feel the way I do, so if > there's some big flaw in my understanding, please do correct it. Sigh... I'm not going to sit here and bicker with you. At the end of the day here is what matters.. Your giving Mike a hard time on the most vital of all programs in this distro and that just sucks so please stop and just be happy that the toolchain works as well as it does. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 15:18 -0500, Tushar Teredesai wrote: > On 7/7/06, Ned Ludd <[EMAIL PROTECTED]> wrote: > > You want a pure 100% > > vanilla(POS) non working toolchain then go download it and > > compile it yourself. You will soon see why things exist the way > > they do.. > > LFS <http://www.linuxfromscratch.org/lfs> has always been based on a > "vanilla" toolchain. Never ran into issues. Of course, we do apply > upstream patches when needed. They patch gcc as needed also. http://www.linuxfromscratch.org/hlfs/ -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 20:40 +0200, Harald van Dijk wrote: > On Fri, Jul 07, 2006 at 01:55:03PM -0400, Ned Ludd wrote: > > Keep pushing this and the only thing you will end up with is the > > vanilla flag being removed all together.. > > Is that a threat? If not, is there a reason behind this? Yes.. When users or devs complain non stop when they don't understand something it leaves us with a few choices. 1) put up with people not having a clue. 2) remove the option so they can't bitch about it. Option #1 is not fun as it pushes the hand on #2 > > You want a pure 100% > > vanilla(POS) non working toolchain then go download it and > > compile it yourself. You will soon see why things exist the way > > they do.. > > If you mean modifying the build system to actually work properly, then I > have no problem with that. USE=vanilla refers to runtime behaviour, not > the build system. (See use.desc.) Specifically, if patches are applied > that make sure GCC compiles, and those patches make sure GCC compiles to > the same program intended by the GCC devs at that release, those patches > are appropriate, IMO. None of the GCC patches I have problems with are > of this nature. > > If you mean vanilla GCC + build fixes is unusable, then I'd appreciate > an explanation, because as far as I know, it can work just fine as a > system compiler, and plenty of people, at some times myself included, > use it as one. You use the Gentoo modified one. Regardless of what USE= flags you have enabled you are still getting Gentoo behaviors. Think vanilla-sources are pure? They are not. They get patched as well with the minimal amount of patches required. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: Gentoo vs GNU toolchain (was Re: [gentoo-dev] Replacing cpu-feature USE flags)
On Fri, 2006-07-07 at 18:53 +0200, Harald van Dijk wrote: > On Fri, Jul 07, 2006 at 04:00:09PM +0200, Kevin F. Quinn wrote: > > On Fri, 7 Jul 2006 07:46:16 +0200 > > Harald van Dijk <[EMAIL PROTECTED]> wrote: > > > > > On Thu, Jul 06, 2006 at 07:44:34PM -0400, Mike Frysinger wrote: > > > > On Thursday 06 July 2006 16:14, Harald van Dijk wrote: > > > > > Gentoo's gcc with the vanilla flag isn't the official GCC. Most > > > > > patches don't get appplied, but some do. Plus, gcc[vanilla] isn't > > > > > a supported compiler in Gentoo. > > > > > > > > you're just griping because i forced ssp/pie regardless of > > > > USE=vanilla ... > > > > > > I didn't mind that you applied ssp/pie patches regardless of > > > USE=vanilla, I did mind that you applied the stub patches with > > > USE="nossp vanilla", and I also didn't like that this was either done > > > accidentally but ignored when pointed out, or that this was done > > > deliberately with a misleading cvs log message. > > > > If you take out the stub patches (which incidentally have no impact on > > code generation), many builds will simply fail because they expect the > > additional flags from ssp, htb etc to be there. > > That's the point. I mentioned being able to test whether your own > software compiles with a pure GNU toolchain as a desire. Being able to > see whether unofficial compiler options are used is not just a nice > extra, but even necessary for that. > > > Since they have no impact on code generation, their presence doesn't > > impact comparisons with a pure upstream release. > > > > > > since gcc-4.0 and below are on the way out, i have no problem > > > > changing this behavior > > > > > > > > besides, since both of these technologies are in mainline gcc now, > > > > i really dont see how you can continue to gripe with gcc-4.1.1+ > > > > > > I don't know how much gcc-spec-env.patch can be trusted, and even if > > > it is 100% safe, such patches don't belong in anything that would be > > > called "vanilla". (I have commented on that patch long before this > > > thread started, so don't think I'm just looking for something to > > > complain about now.) > > > > Again, if you don't gave GCC_SPECS defined in your environment then > > that patch makes no difference to code generation. > > Yes, but if GCC_SPECS is defined in the environment, I don't know enough > about it to be sure that it interacts properly with -specs command-line > options. Even if it works perfectly, though, the point remains that it > does not belong in a USE=vanilla build. Keep pushing this and the only thing you will end up with is the vanilla flag being removed all together.. You want a pure 100% vanilla(POS) non working toolchain then go download it and compile it yourself. You will soon see why things exist the way they do.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
Quite honestly I see this as providing no advantage what so ever over the current USE="mmx blah foo" that we already have.. Please explain to me what I'm missing here.. How does this help us? On Fri, 2006-07-07 at 16:20 +0200, Danny van Dyk wrote: > OK, this rfc/proposal is competing with Flameeye's proposal: > > I suggest to add a "CPUFLAGS" USE_EXPAND variable to the tree. > This should be set to sane defaults in the profiles. I.e. for x86, > it should not set CPUFLAGS at all, and on AMD64 it should be > CPUFLAGS="mmx sse sse2" > > I'm no quite sure, but i assume ppc/ppc32 should leave CPUFLAGS empty, > and ppc/ppc64 should set > CPUFLAGS="altivec". > > > The main reasons for a USE-like implementation om contrast to Diego's > proposal are: > > a) There is no call to gcc involved, but only a call to use(). This >allows usage in metadata phase. > b) There is no implicit (non-transparent) choice made for the users. > c) It doesn't mix CFLAGS' purpose (which has a meaning beyond Gentoo) >with the purpose of optional codepaths. > > I know, there aren't use-based deps in portage yet, but I really feel > uncomfortable to be unable to use cpuflags in metadata phase. This is > what worries me most. > > Danny > -- > Danny van Dyk <[EMAIL PROTECTED]> > Gentoo/AMD64 Project, Gentoo Scientific Project -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 19:09 +0200, Diego 'Flameeyes' Pettenò wrote: > On Thursday 06 July 2006 18:58, Ned Ludd wrote: > > All together as in across the board? Or simply for the 1 pkg > > in question? > For the package in question of course. Do you think I'm an idiot? Seriously? Well. Sorry but there is very little we can assume these days. Just when you think people know what they are doing along comes some hair brained idea that sound ok on the surface but can cause lots of fun problems. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 18:44 +0200, Diego 'Flameeyes' Pettenò wrote: > On Thursday 06 July 2006 17:33, Ned Ludd wrote: > > I tend to agree this might be a cleaner approach vs having to edit & > > redit CFLAGS all over the place. > Really if one has to disable mmx support in one package, it should be > disabled > altogether, in the real world we're all in, mmx useflag is enabled by the > vast majority of our users. All together as in across the board? Or simply for the 1 pkg in question? I seriously hope you are not suggesting across the board cuz that would make me laugh at you for a good hour solid. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 04:40 -0700, Donnie Berkholz wrote:
> Diego 'Flameeyes' Pettenò wrote:
> > echo | $(tc-getCC) ${CFLAGS} -dM -E - 2>/dev/null
>
> > Thoughts? Comments?
>
> How will you handle non-gcc compilers?
Non gcc compilers have never been supported and probably never will be.
Gentoo uses the GNU Toolchain.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 17:09 +0200, Simon Stelling wrote:
> Ciaran McCreesh wrote:
> > You can do it through bashrc. But then, if this is about working around
> > Portage's annoying lack of sane cross compile handling, why not put a
> > little effort into fixing it properly rather than a lot of effort into
> > making the tree more complicated?
>
> Err, I think you're mixing up different things.
> How should portage be
> able to do sane cross compiling if you control the instruction sets
> through use flags which are blocked in profiles the build system is
> using?
That is not the case anymore.. See PORTAGE_CONFIGROOT= and the
attachment as an example which solves this exact problem.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
export PORTDIR=$(portageq envvar PORTDIR)
export ROOT=/dev/shm/blah
export PORTAGE_CONFIGROOT=${ROOT}
PROFILES="$(grep ^[a-z,0-9] ${PORTDIR}/profiles/profiles.desc | awk '{print
$2}' | sort -u)"
mkdir -p ${PORTAGE_CONFIGROOT}/etc/
cd ${PORTAGE_CONFIGROOT}/etc/
for p in ${PROFILES}; do
rm -f make.profile
ln -s ../../../../${PORTDIR}/profiles/${p} make.profile
touch make.conf
ls -ld $(readlink -f make.profile)
emerge --info
done
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thu, 2006-07-06 at 13:19 +0100, Ciaran McCreesh wrote: > On Thu, 6 Jul 2006 12:52:29 +0200 "Diego 'Flameeyes' Pettenò" > <[EMAIL PROTECTED]> wrote: > | Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags > | present in the tree, almost never used to get new dependencies, but > | usually used to supply econf switches. > | > | This works as long as the user enable the flags, but for AMD64 the > | story was, until now, that we simply enabled them when they worked, > | because we had some minimum support available. Unfortunately this > | became a problem with the introduction of nocona, because that is an > | amd64-like system but with no 3dnow. And there is the problem that > | sse3 is supported only in later versions of Athlon64 and so on. > > The other option here... Is to rename the x86 flags to x86_mmx, > x86_3dnow etc, and use amd64_sse3 for amd64 flags, since they're not > really the same as the x86 flags. > > There's probably some USE_EXPAND trickery that can be used here... > CPU_FEATURE_X86="mmx sse" -> cpu_feature_x86_mmx etc might be cleaner? I tend to agree this might be a cleaner approach vs having to edit & redit CFLAGS all over the place. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Announce: standalone libgpm
Please move this thread to the appropriate mailing list.. (ie not this list) On Wed, 2006-07-05 at 14:31 +0200, Enrico Weigelt wrote: > * Mike Frysinger <[EMAIL PROTECTED]> schrieb: > > > > > > Yes, would be better, if it's included in the gpm release. > > > But: it should be possible to build/install it independently from > > > gpm, and also to build gpm against an already installed libgpm. > > > So actually two separate packages, maybe distributed in one tarball. > > > > considering gpm uses autotools, i really dont see why there needs > > to be all that many changes ... write it correctly and it'd be > > easy to fold into configure.ac/Makefile.am > > > > ./configure --disable-binaries > > That doesn't seem to be clean enough for me. I need the libgpm, > and only libgpm, built, and then gpm server built against this > (already installed) libgpm, found via pkg-config. I've got very > strict policies at this point. > > My further plan in short words: > > + further tests on libgpm > + split off the gpm server and rewrite to build against an already > installed libgpm (found via pkg-config) > + put both into some cumulative package, which can be build > just as the current gpm package. > > Meanwhile we also should try to get in the pkg-config stuff, > and let several parts to be switched off as you suggested, > optionally build the server against an installed libgpm, etc. > > > cu > -- > - > Enrico Weigelt== metux IT service > > phone: +49 36207 519931 www: http://www.metux.de/ > fax: +49 36207 519932 email: [EMAIL PROTECTED] > cellphone: +49 174 7066481 > - -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Virtualization Herd
On Tue, 2006-07-04 at 07:59 -0600, Nick Devito wrote: > Yeah, to me, having those in the emulation category just > doesn't"fit" there, but, that's just me. Maybe we could take xen, > vmware, qemu, and related packages out of app-emulation, and make a new > category, app-virtualization. That would seem to fit a bit better then > emulation. Everything looks perfectly fine the way it is right now. Changing stuff for the sake of changing stuff does nothing but cause other people problems. Forcing a package moves which incramentally makes doing package updates take longer and longer over time. It also forces people to run fixpackages more than they really should ever have to. Sometimes even causing a full remerge of the package. Please just be happy that the packages all exist and are being well maintained after. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozilla{-bin}/gecko-sdk masking
On Fri, 2006-06-30 at 22:30 -0500, Jory A. Pratt wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ned Ludd wrote:
> > On Fri, 2006-06-30 at 19:39 -0500, Jory A. Pratt wrote:
> >> As many are aware by now mozilla{-bin} are full of security issues. I
> >> will be p.masking them tonight along with gecko-sdk. This is gonna cause
> >> some issues with stable tree I am aware of this. As packages break
> >> please reference bug http://bugs.gentoo.org/show_bug.cgi?id=137665 If
> >> you are able to provide a patch or diff against problem please provide
> >> and I or the dev/herd that maintaines will test and apply it as soon as
> >> possible.
> >>
> >> I was left with no option as packages are still being updated in the
> >> tree without being ported to seamonkey/firefox. Sorry for any
> >> inconvience this may cause you the user, but devs should be held
> >> responsible as they have had plenty of time to work out the problems.
> >
> > I've been using seamonkey for a few weeks now without problems and am
> > pleased with it but I don't believe a word you say about having no
> > choice or devs having the option to fix stuff. You always had the
> > option of porting patches. You always have options! You have held back
> > taking the seadonkey out of p.masking till the very last min then
> > forced an un-smooth upgrade path on everybody. Please don't shift the
> > blame on others.. We have ~arch and blockers for stuff like this...
> >
> > Please don't take this as a personal attack... I'm just calling shit as
> > I see it.
> >
> >
>
> If this is how ya feel back port the damn patches. I do not have time to
> back port patches for every security issues that remains. I have fought
> to keep security from masking it before now. Maybe you would feel better
> taking over mozilla/seamonkey/gecko-sdk? If all the bug mail over the
> last week is not enough to move the tree to were it should be already
> for seamonkey as I have requested, then the responsibility does fall on
> package maintainer.
>
>
> For those who are unaware just follow all the blockers you will end up
> at security were there has been comments about back porting patches but
> you have not seen solar make any mention of who/when will or has the
> time to do the back porting.
My reply to your orig mail was intended to be off list.
Lack of time is fully understandable. It's a big package and takes a
long time to compile and debug. More time than many are willing to
devote.. Trust me I thank for you doing what you do and have no interest
what so ever in maintaining the pkg either. I just feel that mozilla is
a pretty major package and seamonkey if unmasked current has not been
unmasked for very long ~10 hrs as of this mail. As long as the two
existed in the tree and blocked each other there seems a little less of
a rush to be so quick to p.mask mozilla itself till the bugs are fleshed
out of the seamonkey pkg. Most maintainers put stuff into ~arch so bugs
can be worked out. You jumped it right to stable out of a p.masking
Shrug.. It's your pkg feel free to maintain it however the fsck you
want..
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozilla{-bin}/gecko-sdk masking
On Fri, 2006-06-30 at 19:39 -0500, Jory A. Pratt wrote:
> As many are aware by now mozilla{-bin} are full of security issues. I
> will be p.masking them tonight along with gecko-sdk. This is gonna cause
> some issues with stable tree I am aware of this. As packages break
> please reference bug http://bugs.gentoo.org/show_bug.cgi?id=137665 If
> you are able to provide a patch or diff against problem please provide
> and I or the dev/herd that maintaines will test and apply it as soon as
> possible.
>
> I was left with no option as packages are still being updated in the
> tree without being ported to seamonkey/firefox. Sorry for any
> inconvience this may cause you the user, but devs should be held
> responsible as they have had plenty of time to work out the problems.
I've been using seamonkey for a few weeks now without problems and am
pleased with it but I don't believe a word you say about having no
choice or devs having the option to fix stuff. You always had the
option of porting patches. You always have options! You have held back
taking the seadonkey out of p.masking till the very last min then
forced an un-smooth upgrade path on everybody. Please don't shift the
blame on others.. We have ~arch and blockers for stuff like this...
Please don't take this as a personal attack... I'm just calling shit as
I see it.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Future developer
Congratulations on your cloning efforts. On Fri, 2006-06-30 at 21:54 +0200, Paul de Vrieze wrote: > I'm proud to announce the arival of a future developer. His name is "Tom". He > arived last monday on 10:22 am (UTC+02). I and my wife will take care of > mentoring him to full developership ;-). > > In the meantime, he's got his own album on > http://www.cs.ru.nl/~pauldv/tom/ > > Paul > > ps. If I'm a bit away these days, it is due to me being preoccupied with my > mentoring task. > -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] fix binary debug support, part elevenity billion + 1
On Thu, 2006-06-08 at 09:54 -0700, Donnie Berkholz wrote:
> Ned Ludd wrote:
> > On Thu, 2006-06-08 at 07:49 -0700, Donnie Berkholz wrote:
> >> Ned Ludd wrote:
> >>> -for conf in ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> >>> +for conf in default ${PN}-${PV}-${PR} ${PN}-${PV} ${PN}; do
> >>>
> >>> Call it 'default' ?
> >> Switch the order around so it's 'default PN PN-PV PN-PV-PR' -- that way
> >> you can have a package-specific setting, and override it for specific
> >> versions.
> >
> > You mean this if only the 'break' is in not in there right?
>
> Didn't catch that on the quick glance -- Actually I'd like if you
> removed the break so you can do what I suggested.
This is in the tree now with all suggestions made by everybody and
works with the new PORTAGE_CONFIGROOT variable also.
--
Ned Ludd <[EMAIL PROTECTED]>
Gentoo Linux
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo-dev-announce list
On Mon, 2006-06-26 at 17:36 -0600, Lance Albertson wrote: > Donnie Berkholz wrote: > > > Agree, but with the caveat that devs must still be at least subscribed > > to -core even if they choose not to read it. This way, you could have a > > -dev-announce that also refers to something private on -core if need be. > > > >> Now, do we really need it to be -core-announce? Not really. In fact, > >> at one point we'd come up with both a -core-announce and a > >> -dev-announce, with -core-announce being for more sensitive information. > > > > I'm having a tough time thinking of sensitive information that all devs > > must know about (i.e., that would qualify for -core-announce). > > I'd rather not create a -core-announce. The amount of times those types > of things come up on the list are rare. It would be easier to have an > standard subject heading (maybe ANNOUNCEMENT:) that people can use in > their filters. If devs start abusing it, then we'll vote them off the > island :) Simple, Effective.. I like it.. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] Resignation
On Sun, 2006-06-25 at 10:33 -0500, Jory A. Pratt wrote: [snip] > P.S > I will not leave you all the users with noone to maintain the packages > that 98% of you all depend on when it comes to a browser. Thanks.. /me guesses you had a few brews when you wrote said mail. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] gentoo-dev-announce list
On Sat, 2006-06-24 at 20:06 -0700, Donnie Berkholz wrote: > This topic has come up in the past, and I'd like to revive it once > again. The gentoo-dev list has gotten a lower and lower signal to noise > ratio over the past year or two, and it's difficult to dig out the stuff > that's truly required reading. > > I propose that all need-to-know announcements and decisions be posted to > a separate, moderated (or restricted posting) gentoo-dev-announce list > to ensure that no developers lose track of what really matters. > Hopefully, this will also help to give more focus to discussions on > gentoo-dev because the goal will be to get a real decision to send to > gentoo-dev-announce. I would be in favor of a gentoo-dev-announce list if it allowed me to unsubscribe from this list. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] sunrise, a temporary compromise
On Thu, 2006-06-22 at 19:05 -0500, Mike Doty wrote: > All- > > We've had a discussion about sunrise and have reached a compromise. > Someone will summarize it later, I've attached the raw logs for now. > Until the council makes a firm decision about non-gentoo hosted > overlays, this will be the defining method of dealing with them. > [snip log] Ok if I may chime in. Some people seem to have a problem with devrel enforcement of a council recommendation. As the council itself was never asked to make a hard decision on the fate of sunrise, but only asked to discuss it. We the council discussed it and made a soft recommendation. So to me it appears that devrel is doing it's job and is perfectly within bounds in the following up of council recommendation till such time as sunrise matures enough to be re-evaluated. With respects to Gentoo trademarks. That is a foundation issue and would have to be raised with them. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] embedded overlay on overlays.gentoo.org
On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote: > Hi, > solar has requested an account on overlays.gentoo.org for the embedded > overlay for you. > Your password: DX7wnSe40Y think you can change my pw and lets do this offlist? -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
On Wed, 2006-06-14 at 17:25 -0400, Chris Gianelloni wrote: > On Wed, 2006-06-14 at 14:47 -0400, Ned Ludd wrote: > > On Wed, 2006-06-14 at 09:13 -0400, Chris Gianelloni wrote: > > > > > Just because the maintaining *project* doesn't > > > want it doesn't mean it doesn't belong to that herd. > > > > This is incorrect and you should not encourage people to add pkgs to > > a herd unless they get permission from that herd. If a herd does not > > want it you shall not shit in their home (it's rude). > > A herd doesn't *want* anything. It is a group of packages. Perhaps you > mean a maintaining project? Nope not at all see below. > > > When a package lists a herd then the responsibility is shared > > among the maintainer and the herd. > > Only if someone didn't list themselves as the maintainer, which would be > wrong. Just because the games team doesn't maintain something doesn't > mean it isn't a game anymore. I think you are confusing a category/ vs a herd. But in the case of games@ only we can take your note and keep it in mind when adding new packages to the tree to go ahead and slap a games@ on it. But sorry not the rest of the tree. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
