Re: [gentoo-dev] Available hardware
On Tue, 2008-01-15 at 18:27 -0800, Chris Gianelloni wrote: > On Tue, 2008-01-15 at 16:25 -0800, Daniel Ostrow wrote: > > 1x HP ZX2000 1.4 GHz Itanium2 > > I know that you said off-list, but I'm stating this here simply because > I want to make sure people know that I have "dibs" if this meets my > needs. > > Can this box be upgraded to SMP? > > If not, I rescind my "dibs" since mine is more powerful. I just want to > be able to have decent video so I can do games on IA64. As you know, my > Itanium box is a server without AGP and with only PCI-X (so PCI video is > my only choice). Consider your dibs rescinded. It is uni-proc only. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Available hardware
On Tue, 2008-01-15 at 16:25 -0800, Daniel Ostrow wrote: > All: > > As I am no longer an ebuild dev (real life job got in the way) I have a > whole slew of hardware that I'm willing to ship to any gentoo dev for > the cost of shipping alone. The list of hardware is as follows: > > 1x HP C3700 750 MHz PA-RISC > 1x Dec/Compaq PWS 600 600 MHz Alpha > 1x SGI Octane2 Dual 195 MHz Mips > 1x HP ZX2000 1.4 GHz Itanium2 > 1x Apple G4 1.25 GHz PPC32 > > I also have a slew of SPARC hardware, need to go home and catalog that, > not all that sure what all I have. I can answer any questions about the > other specs of the machine upon request. > > If anyone is interested contact me off list. I live in northern > California for shipping reference. G4 has been spoken for. signature.asc Description: This is a digitally signed message part
[gentoo-dev] Available hardware
All: As I am no longer an ebuild dev (real life job got in the way) I have a whole slew of hardware that I'm willing to ship to any gentoo dev for the cost of shipping alone. The list of hardware is as follows: 1x HP C3700 750 MHz PA-RISC 1x Dec/Compaq PWS 600 600 MHz Alpha 1x SGI Octane2 Dual 195 MHz Mips 1x HP ZX2000 1.4 GHz Itanium2 1x Apple G4 1.25 GHz PPC32 I also have a slew of SPARC hardware, need to go home and catalog that, not all that sure what all I have. I can answer any questions about the other specs of the machine upon request. If anyone is interested contact me off list. I live in northern California for shipping reference. Thanks, --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Introducing new lead for xfce herd and project.
On Wed, 2008-01-16 at 00:06 +0200, Samuli Suominen wrote: > Since dostrow is being retired or is retired, correct me if I'm wrong > we decided (actually we rolled dices :-) that welp is the new lead. Not really retired, just not doing ebuild work anymore (only doing events management for LWE and the like). That being said, congrats welp! --Dan signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-nfp] Nominations open for the 2007/08 Trustees
> 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. Just went trough this with another project I belong to and I think it would be a GREAT idea. granted would have to be accepted by the developer population but I for one know that when I was a trustee I was rather paralyzed by fear doing anything with the NFP entity. Please please pleasey please do this! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ML changes
One additional note, my proposal doesn't account for controlling flaming, disrespect or general asshatery (discounting outright ridiculous things like blatantly insulting people, that's a no-no). That I am afraid is just one of the natures of communities our size. There is no way we can curtail people from speaking their minds publicly, if you ban someone from a list they will find somewhere else, equally as public, to be an asshat...and now they have valid ammunition...granted this "somewhere else" won't necessarily be visible to you (for any value of you) so your panties might get less bunchy...but frankly any damage will still be done... The point is so that you can *ignore* it when it happens...trying to stop it is an exercise in futility and will only make your hair gray and your stress level increase...people will be assholes...that's just people I'm afraid... signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] ML changes
On Thu, 2007-07-12 at 13:24 -0700, Mike Doty wrote: > All- > > We're going to change the -dev mailing list from completely open to where only > devs can post, but any dev could moderate a non-dev post. devs who moderate > in > bad posts will be subject to moderation themselves. in addition the > gentoo-project list will be created to take over what -dev frequently becomes. > there is no requirement to be on this new list. > > This will probably remove the need for -core(everything gets leaked out > anyway) > but that's a path to cross later. > > We're voting on this next council meeting so if you have input, now would be > the time. It is rare enough that I actually respond to something on -dev (or any ml for that matter) so you know I have to care... Personally, I rather dislike this proposal, mostly because I see it as a bunch of unnecessary work... I as a developer find it very difficult to cut though what I consider noise to find the bits that I consider important to being able to continue being an effective developer on a list that I am *required* to be subscribed to. We have considered the likes of a moderated list, an announce only list and now this sillyness to help in cutting down on what a lot of us see as noise. How about we try something elsea self moderated quasi-announce list... 1). Create 1 (ONE) new list, which, for the purposes of this discussion I will call it gentoo-dev-info (the name matters not). The requirement for subscription for all devs would shift from gentoo-dev to gentoo-dev-info. 2). All *new* threads should cross post (regardless of whether it is from a dev or a user) to both gentoo-dev and gentoo-dev-info. Those that don't cross post (either by ignorance or accident) can be forwarded by someone to the missing list. 3). The reply-to header for gentoo-dev-info should be set to gentoo-dev. 4). No further e-mail will be sent to gentoo-dev-info on this new thread until a resolution on what actions if any need to be undertaken. 5). If a thread topic is posted that interests you as a developer (or a user for that matter), you can either a). sub to gentoo-dev to continue discussion there, b). utilize any of the archives to follow the topic and contribute without being subscribed or c) have already been subscribed and only pay attention to this one thread sending the rest to /dev/null (yay! procmail). 6) After the thread has petered out, if, and only if, any action is being taken, be that a change in policy, a clarification of policy or an actual change in behavior of some component, the dev or devs who are going to take said action send a notice describing it as a follow up notice to both gentoo-dev and gentoo-dev-info. Using that model devs and any users that want to subscribe as well can be aware of every new thread that gets started and choose to participate or not. This also gives them a new list that should have almost no noise, every thread will be at most two e-mails long, the initial e-mail and the resolution (if any). If you don't care about a topic all you see is that it was discussed and what the outcome of said discussion was, if you do care, you involve yourself in the discussion at your pleasure. We can trust people on their honor not to post to gentoo-dev-info in any manner other then that described above. This way we avoid the whole overhead of having to moderate the list, if people misbehave and post additional crap to the list consider moderating that one user...but honestly since there is a list *with the same thread* meant for discussion already this should only happen out of ignorance of policy or malicious action...the latter should be clearly identifiable and dealing with it should be easy. No need to change the status quo for dev, no need to privatize core, just create one list, post the rules and off you go... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] setarch and util-linux (amd64/mips/ppc/sparc)
On Sat, 2007-07-07 at 01:39 -0400, Mike Frysinger wrote: > the new util-linux package has merged the setarch binary. for the upgrade > path, i figure we do: > - drop sys-apps/setarch from profiles > - add sys-apps/setarch to util-linux-2.12 based on arch?() > - add !sys-apps/setarch to util-linux-2.13+ > > any input ? Go for it. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] gentoo-dev-announce list
On Thu, 2007-06-21 at 14:09 -0700, Donnie Berkholz wrote: > Hi all, > > I'm back for my yearly posting about creating a gentoo-dev-announce > list [1]. Fedora recently created a fedora-devel-announce list with a > great description of how it works, what's posted to it, etc [2], which > got me excited about making this happen in Gentoo. > > Last time the issue came up, numerous people supported it, but nobody > followed through to get the list created. This time, I'm going to file > a bug to the infra team to make it happen. > > What's this mean for you? If you want to ignore -dev, you can just > subscribe to -dev-announce. But you will lose your ability to > participate in discussions leading toward decisions. If you have an > announcement relevant to development, post it to both -dev > and -dev-announce. Replies will go only to -dev. Can I get an 'AMEN'! ++ ++ ++ some more ... oh and ++ --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] how to handle sensitive files when generating binary packages
On Wed, 2007-06-20 at 16:08 -0700, Chris Gianelloni wrote: > On Wed, 2007-06-20 at 23:35 +0100, Ciaran McCreesh wrote: > > On Wed, 20 Jun 2007 15:31:32 -0700 > > Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > > On Wed, 2007-06-20 at 22:01 +0100, Ciaran McCreesh wrote: > > > > The specific underlying question being, what are the use cases for > > > > binary packages? > > > > > > Ever managed a network of multiple Gentoo identical Gentoo machines? > > > > That's one use case, yes. Now what are the others? > > Release building... Backups... Testing newer packages... > > Oh yeah,and who said we really needed more than one use case? I think > providing tools to allow Gentoo to be adopted in the corporate > environment is reason enough to have binary package support, and I feel > that many people will agree with me. > The issue isn't whether or not we should have them, or for that matter whether or not there is more then one use case. The issue is making sure that we know what the use cases are to ensure that the tools we have are flexible enough to be able to support every case and so that we don't paint ourselves into a corner by making decisions before we know how people plan on using the tool. At least that is how I see it... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: QA issue: No stable skype in Tree
On Mon, 2007-06-18 at 21:11 +0200, Wernfried Haas wrote: > On Mon, Jun 18, 2007 at 11:39:26AM -0700, Chris Gianelloni wrote: > > Internet Explorer doesn't even *run* on Gentoo. If it did, it > > would likely be in the tree since quite a few people would likely use > > it, even if just for testing. I know that if I were able to test things > > on IE from Linux without having to fire up VMware that I would be quite > > happy. > > Haven't tried it, nor do i care about IE, but i ran into that a while ago: > http://www.tatanka.com.br/ies4linux/page/Main_Page > > cheers, > Wernfried > > PS: No, i'm not posting this for the sake of proving IE works on > Gentoo, just as information for people who may need it. Funny as it may be, and 100% off topic, so yes this is just noise, I use ie6 under wine via ies4linux every day...and yes...it makes me feel very very very dirty. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New (old) Developer: Deedra Waters (dmwaters)
On Mon, 2007-06-04 at 18:08 +0200, Christian Heim wrote: > It's my pleasure to welcome back Deedra Waters (also known as dmwaters on > IRC). > > Deedra is joining us from Pensacola, FL. She is going to work on the > accessibility stuff (she is blind), will be re-joining Developer Relations, > and helping the kernel people to fix sparc/amd64 related kernel problems. > > So please give Deedra a warm welcome ! YAY! One of my favorite people is back. :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 1/2 OT: splitting packages
On Mon, 2007-05-14 at 23:18 +0200, Enrico Weigelt wrote: > Hi folks, > > > I know this issue is not actually in the scope of this list, but > maybe some of you might be interested: > > Lots of packages have optional parts which (IMHO) should/could be > their own packages, ie. GUI frontends to console tools (aumix) or > several language bindings of certain libs/toolkits. > > Those things tend to produce circular dependencies, which can > only be solved with tricks like multiple builds, special useflags > like "build" or "bootstrap". > > For example berkeley db: it written in C and has additional > bindings for C++ and Java. This produces two kind of problems: > > a) for the base system we must take care that it's built w/o them. > b) if some package needs an special binding, dependencies get tricky >(AFAIK portage cannot solve feature deps yet) > > An clean solution would be having the bindings as separate packages. > Of course, often the upstream is not ready for this yet, and it's > not in the scope of an distro like gentoo to such heavy changes. > > But those splits really should be done (IMHO) to make things a lot > easier. So let's do it - do the split and try to convince the > upstream to get it in. We release our packages as upstream intends. If they don't split them, we don't split them, talk to upstream not us. This is what use flags are for... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Linux 2.6.21 plans
On Wed, 2007-05-09 at 00:36 +0100, Mike Auty wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hiya, > Reading over the discussion on lkml, it appears that it only affects > x86_64 systems... > Mike 5:) Mine is an x86_64 system...it also only seems to affect early adopters of VMWare Workstation 6, which hasn't been released yet no less considered *stable*. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Linux 2.6.21 plans
On Wed, 2007-05-09 at 01:11 +0200, Florian D. wrote: > Daniel Drake wrote: > > Hi, > > > > 2.6.21 was released today. Testing muchly appreciated as usual -- please > > file bugs and clearly mark them as 2.6.21 regressions if that is the case. > > > > hello, > 2.6.21 will break the current *stable* VMware worstation. VMware 6 will work > again. please see the > following thread on LKML: > http://marc.info/?t=11779983523&r=1&w=2 > > I didn´t file this on bugzilla, because its an upsteam thing anyway. I still > think its a good idea > to upgrade to 2.6.21 -- just put a note on GWN or something. > > cheers, f UmmmI use VMWare Workstation every single day for wonk on my laptop, I'm running 5.5.3.34685 and 2.6.21.1 without any issues what so ever... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New project: Gentoo Artwork
On Sat, 2007-04-28 at 22:04 -0400, William L. Thomson Jr. wrote: > On Fri, 2007-04-27 at 11:28 +0200, Bjarke Istrup Pedersen wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > It would be nice if there where some CD/DVD labels created, that people > > could print and put on their LiveCDs/InstallCDs :-) > > Yes that would be quit nice. At LWE in 06 we were handing out cds we > were burning with hand written labels. So for any events were we give > out livecds and etc. Would make a big difference at least in first > impressions for many, IMHO. > This year I'm thinking of just doing lightscribe media, much easier then having to deal with labels, the don't come off and they don't wear out. Still a common format for the image would be WONDERFUL!!! signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
> The *only* downside that I can see here is that by default the package > installation process gets a little longer. To get around this some > method of globally opting out of src_test should be provided to the end > user, however since it is an on by default feature someone at least has > *tried* the test suite. More to the point a facility to opt out either on a per-package basis or globally should be allowed. But that is an implementation detail not a specification one. The spec should say that running src_test is default. There is nothing in that statement that says that there shouldn't be a way to turn it off if the end user doesn't want it. Take paludis for example, with SKIP_FUNCTIONS you can already do this with a simple case statement, that however as I said is implementation specific not a spec issue. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] EAPI 1 (Was: Re: Monthly Gentoo Council Reminder for April)
> > > Er, no, I'm explaining why enforcing src_test for EAPI 1 will be > > > helpful for an awful lot of Gentoo developers. > > > > except that you back the tree into a corner that it cannot come out of > > Huh? Not at all. If a package can't use its test suite, the ebuild can > set RESTRICT=test. > > > > Please refrain from that kind of comment. It doesn't help anyone. > > > > the answer is the same: talk to the QA team to get the tree into a > > state where having src_test enabled by default is feasible and then > > the QA team can change the profile > > That isn't going to happen any time soon. There are too many changes > and the impact of turning it on is too high. A gradual migration via > EAPI is much safer and much more useful. > > > enforcing via spec is the wrong way to go here ... spec is for > > defining how the ebuilds work, not for forcing policy down peoples > > throats > > And whether or not src_test is called is part of how ebuilds work. > Policy is whether or not src_test is required to do something in all > situations, or whether it can be RESTRICTed out as necessary. First off...wow...long time since I've been active...so if anyone wants to discount my comments based on that alone feel free. I'm trying to get back in the game and I think a few e-mails as participation might be best...hopefully you'll actually see me online soon. Now on to the real topic at hand. For src_test I see things this way. 1). Even though src_test is not mandatory in the here and now any package that provides a test suite that fails said tests has a bug. It may not be a critical bug but it is in fact a bug. 2). The proper fix, again in the here and now, for said bug is either to a). fix the test suite or b). add a RESTRICT="test" to the ebuild. Since sec_test is not mandatory however these things happen rarely if at all. With the above in mind I entirely agree that adding it as a mandatory phase for EAPI=1 makes sense. Think of it this way: 1). Developer A is bumping a package and is including some new functionality in his ebuilds that require something in EAPI=1, say for example a SLOT dependency. As such Developer A is already editing the ebuild *and* testing it. 2). As part of his test he checks if the built in test suite works, something he should be doing *anyway*. If it does great, if it doesn't then he has two choices, as above, fix it or add a RESTRICT="test", at *worst* adding 15 whole characters (16 if you include the extra carriage return he will need to add) to his ebuild. 3). Developer A then marks his ebuild as EAPI=1 and off he goes on to bigger and better things. This will allow a whole slew of VERY useful information to be available: 1). The QA team can now query the tree for packages that have known bad test suites simply by looking for ebuilds that have RESTRICT="test". As it stands now this is impossible to accomplish. 2). Interested volunteers, both developer and user alike, who are looking for ways to help out, can now be given a concrete list of known test suites to go and fix, this improves the QA of the packages in the tree. 3). The fact that a bug in the test suite exists is no longer hidden from view. 4). Since the test suites are now mandatory end users can feel more confident in the state of their installed software, this is no silver bullet but it is a step in the right direction. The *only* downside that I can see here is that by default the package installation process gets a little longer. To get around this some method of globally opting out of src_test should be provided to the end user, however since it is an on by default feature someone at least has *tried* the test suite. Again, since src_test would only be turned on by default for ebuilds marked EAPI=1, not globally for the whole tree, the only additional work required of developers would be to actually run the test suite and possibly fix a bug in one of two accepted ways. After all, the ebuild is being touched *anyway*. As with all the phase changes under discussion *no one* is talking about making a global tree change, src_test would just be default for those ebuilds that have EAPI >= 1. Just my 2 cents... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-core] Re: [gentoo-dev] New profiles/ChangeLog
On Fri, 2007-01-12 at 10:00 -0800, Donnie Berkholz wrote: > Chris Gianelloni wrote: > > There's a ChangeLog file in profiles/ChangeLog now. Please use it when > > making changes to things in profiles/*... > > Should we prefer this location for trees that already have a ChangeLog > in them as well? It's kind of random which places have a ChangeLog and > which don't. > > [EMAIL PROTECTED] profiles $ find . -name ChangeLog > ./ChangeLog > ./default-linux/alpha/ChangeLog > ./default-linux/amd64/ChangeLog > ./default-linux/hppa/ChangeLog > ./default-linux/ia64/ChangeLog > ./default-linux/ppc/ChangeLog > ./default-linux/sparc/ChangeLog > ./default-linux/x86/ChangeLog > ./hardened/x86/ChangeLog Not really randomshould be something akin to one per arch (for releng/arch team purposes) and then on global one to accommodate everything else... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Monthly Gentoo Council Reminder for November
On Wed, 2006-11-08 at 17:37 +, Kurt Lieber wrote: > On Wed, Nov 08, 2006 at 07:19:44PM +0200 or thereabouts, Alin Nastac wrote: > > I say we should have +all (SPF-capable MTAs will consider any IP address > > as authorized to send mail on behalf of g.o - equivalent with "Message > > source OK"). > > this interpretation is correct. > > > He says we should have ?all (when another SPF-capable MTA will check the > > my IP address, it will take my message with a grain of salt - equivalent > > with "Message source unknown"). > > this interpretation is not correct. What you are describing is ~all, not > ?all. ?all instructs the MTA to make no interpretation at all related to a > failure. In other words, do not add or subtract any salt whatsoever.[1] > ~all tells the MTA to add some salt.[2] > > --kurt > > [1] http://new.openspf.org/RFC_4408#op-result-neutral > [2] http://new.openspf.org/RFC_4408#op-result-softfail Not advocating either option...just pasting additional info. If anyone wants to see the VERY brief discussion that was had over at SA about why they decided to ignore the standard (or moreso what they decided the standard actually meant) check out [1]. --Dan [1] http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3616 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: per-package default USE flags
On Sun, 2006-10-15 at 22:01 +0100, Ciaran McCreesh wrote: > On Sun, 15 Oct 2006 22:35:10 +0200 Jakub Moc <[EMAIL PROTECTED]> wrote: > | > Which is why I suggested changing Portage's behaviour earlier in the > | > thread. Like it or not, overlays are already getting complex enough > | > that they'd benefit from profile behaviour. > | > | Because maintaining your own profiles and stacking them and dealing > | with all the related mess is a _lot_ easier that sticking a + before > | foo in IUSE. Right. ;) > > You mean, than sticking a + before foo in IUSE in every ebuild, and > ensuring that changes are kept in sync and consistent with the > behaviour of every single existing profile. No one here is talking about doing that... What we are talking about is an instance where foo is *not* enabled by default in profiles but there is *one* package where it is upstreams intention that foo be enabled by default but they still provide the capability to turn foo support off. This package (and all of the ebuilds that are in the tree for it) would have a +foo in IUSE...thus even though foo is generally off unless the user specifies -foo in either make.conf or package.use foo is turned on for this package and this package alone. No one is talking about replacing tree wide defaults with this functionality...this is for package maintainers to specify default behavior for their package and their package alone independent of the profiles intent. Doing it your way in order to make sure that a package was built the way a maintainer intended (by default) they would have to make an entry in package.use in every single tier one profile (at the moment only base)...this is also something that they cannot enforce over external overlays...so it looses any value at all. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] CFLAGS paragraph for the GWN
On Tue, 2006-10-03 at 19:16 +0200, Lionel Bouton wrote: > Josh Saddler wrote the following on 03.10.2006 18:11 : > > (...) > > > Lionel > > Uh, Gentoo-wiki does not get linked. > > Are there many trying to link to the Gentoo Wiki in official > documentation? It seems guns are warm and devs quick to jump to > conclusions (re-read the title and the previous discussion on this very > subject) :-) Keep cool, I agree with your statement (for numerous > reasons), it's just out of context: I propose a 'reminder' chapter for > the GWN, that's all. Ok...lets try this... Gentoo-wiki does not now nor will it ever get linked to from official Gentoo media, documentation, or anything else within the www.gentoo.org namespace... It is inherently unreliable and outside of Gentoo's control. It will eat your dog, kill your cat, club baby seals and make the hole in the O-Zone layer bigger... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New project: Gentoo Seeds
On Wed, 2006-09-20 at 18:42 -0400, Alec Warner wrote: > This whole thread is quite disappointing to me. Someone comes up with a > new way to use Gentoo; to make it a viable tool for a job; to make it > USEFUL. This is what we are about here (or were?). > > "Put another way, the Gentoo philosophy is to create better tools." > > -Daniel Robbins > Previous Chief Architect > > So unless that has changed and no one has updated the webpages... Here is my take on the issue, it's something I saw happen when Gentoo on Mac OSX was announced, again with Sunrise, and now with Seeds (also note I'm not making a value judgment about any of the aforementioned projects, I just note a similar progression of events). There are those among us (myself often included, and mostly because I had a hand in the way the OSX port was handled at the outset) that believe that you shouldn't announce things in the manner of "Gentoo is doing XYZ now." in public fora (lists, gwn whataveyou) without first talking internally to verify the viability of the project, it's impacts on other projects, potential points of collaboration etc. This also coming up with a rational reference implementation and a list of tools that you will need. Now I realize that this means that there is less public visibility for projects in their larval stage, which can mean less (new) hands helping to figure out the above, but it also means an informed set of peers and no surprises. I believe that what Ciaran (and others) have been trying to say with suggesting that a GLEP might have been worthwhile isn't so much the statement that this (or any of the other projects) necessarily *need* a GLEP per se, but the GLEP process itself can act as a method to hash out any issues *and* inform your peers. Maybe we just need something along the lines of a GLPP (Gentoo Linux Project Proposal) mechanism wherein the Council specifically does *not* need to approve the project, or for that matter be involved at all, but can, at their discretion, deny the project existence. The format of the proposal could follow that of the current GLEP structure, and it's entire purpose would be to foster peer review and to spread information. Once a general level of consensus, and not I specifically did not say a full consensus, is reached then the project can officially be "born". Hell we just recently went through the whole process of coming up with a good GLEP to disseminate news to our users and it seems that we have the same problem internally... A lot of it comes down to wording in my mind, and granted it is a bunch of semantic bull but words matter. For instance in Stuart's original e-mail (and I'm sorry to pick on you, just happens to be the topic at hand) the subject was "New project: Gentoo Seeds" and the first paragraph read "I've created a new project, called Gentoo Seeds [1]. The aim of the project is to create stage4 tarballs which can be used to 'seed' new boxes with ready-built Gentoo solutions." A simple change to Subject: "New Project Proposal: Gentoo Seeds" with the first paragraph being "I'd like to create a new project, called Gentoo Seeds [1]. The aim of the project would be to create stage4 tarballs which can be used to 'seed' new boxes with ready-built Gentoo solutions. If you are interested in working on this type of project come by #foo or discuss it here. I will be sending all online discussions to the list so that the community can stay informed. Once we get a finalized plan we'll create an official project." It really comes down to understanding that once it is called a project it should already be known to be a good idea, and the whole community should have had time to think about it. In the court of public opinion there is a huge difference between saying "Gentoo has a project providing XYZ service." and "Gentoo is looking into the viability of providing XYZ service." Especially when it comes to the potential failure of that service. It looks *way* better to say "We found out that the project would not have been viable." or "We had to modify our idea in this way to make it viable." then causing what happened today. I'd also say that the *first* discussion of any new projects should happen on internal lists with the *first* round of comments coming from within the dev ranks. That way, if a project is particularly untenable mention of it won't ever have to be made public. If it is clear that the project just needs some shake out time then discussion could move to a public list for further scrutiny and community involvement. Again...all semantics...and a load of bull...but bull matters. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] New project: Gentoo Seeds
On Wed, 2006-09-20 at 00:56 +0200, Carsten Lohrke wrote: > First step should imho be, that you work with the Portage team on having > proper set support implemented. Current meta ebuilds do suck, really. No need for meta ebuilds...stage4 specs + catalyst. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Paid support
On Sat, 2006-09-09 at 21:23 -0700, Daniel Ostrow wrote: > On Sat, 2006-09-09 at 15:03 -0400, Chris Gianelloni wrote: > > On Sat, 2006-09-09 at 18:49 +0200, Ioannis Aslanidis wrote: > > > I am just wondering, how does this affect European developers? Does this > > > make us financially active in the US even if we work for a European > > > company due to the fact that we are bound to Gentoo Foundation which > > > *is* registered as a NFP Organization in the US? What are our > > > responsibilities from the juridic point of view in the US and in the EU? > > > > If you are not working for a US company, then US law does not apply. > > This is exactly the point that I am trying to get across. This is no > > different than someone contracting you now. You would be required to > > follow the laws that govern a normal contract. If it is within the same > > country, then the laws of that country. If it is across international > > borders, then you would be required to do whatever is necessary > > according to the laws of both countries. The only reason that US law > > would be used is if you either live in the US or are working for a > > company in the US. > > That and it is all an entirely moot point as the Foundation would not be > making money in any way shape manner or form it is no different from > HotJobs, Monster, or the Penny Saver...we would be connecting people > with jobs...NetBSD already does this > btw...http://www.netbsd.org/gallery/consultants.html and they are a > *more* restrictive 501(c)3. Oh and to forestall the argument ... those three companies charge for their service...we would not...so again, moot point. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Paid support
On Sat, 2006-09-09 at 15:03 -0400, Chris Gianelloni wrote: > On Sat, 2006-09-09 at 18:49 +0200, Ioannis Aslanidis wrote: > > I am just wondering, how does this affect European developers? Does this > > make us financially active in the US even if we work for a European > > company due to the fact that we are bound to Gentoo Foundation which > > *is* registered as a NFP Organization in the US? What are our > > responsibilities from the juridic point of view in the US and in the EU? > > If you are not working for a US company, then US law does not apply. > This is exactly the point that I am trying to get across. This is no > different than someone contracting you now. You would be required to > follow the laws that govern a normal contract. If it is within the same > country, then the laws of that country. If it is across international > borders, then you would be required to do whatever is necessary > according to the laws of both countries. The only reason that US law > would be used is if you either live in the US or are working for a > company in the US. That and it is all an entirely moot point as the Foundation would not be making money in any way shape manner or form it is no different from HotJobs, Monster, or the Penny Saver...we would be connecting people with jobs...NetBSD already does this btw...http://www.netbsd.org/gallery/consultants.html and they are a *more* restrictive 501(c)3. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] council voting reminder
One last reminder...this weekend is the last weekend polls are open. Polls close at 00:00 UTC on Monday the 11th so if you haven't voted yet now is the time...lets see if we can break the 50% turnout mark! --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What would Freud say? New developer; Mike Kelly!
> > So yeah, buy him a pint and welcome him onboard! > > SMTP, IMAP and POP3 don't support that. > What...you have never heard of PPP, the Pint to Pint protocol... (Sorry about this clear waste of bandwidth...it's early and my pun senses still have control of my fingers...) --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What would Freud say? New developer; Mike Kelly!
On Wed, 2006-09-06 at 01:22 +0100, Christel Dahlskjaer wrote: > Hailing from Pittsburgh, PA, the cognitive science department at > Carnegie Mellon University comes Mike Kelly aka pioto. Already known by > some of us from his excellent work on dynusers[1] during this years > Summer of Code he now comes onboard to put it in the tree and > maintaining it, apart from having implemented GLEP 27 he has previously > contributed some ebuilds, such as net-im/zephyr. He'll no doubt take up > some more interesting stuff besides dynusers, that is, if he finds time. > Although he is taking a gap year before returning as a fourth year > student at CMU he keeps busy by doing watersports. Yes, watersports. I > took a double take at that one, before realising he was talking about > water polo and swimming. He comes prepared, Boy Scout and all! > > I of course am most thrilled to find that we've another developer with a > keen interest in the human brain, he may not be able to read your mind > but he does speak bash, C, C++, Java, Perl and some sml. > > So yeah, buy him a pint and welcome him onboard! Welcome to the insanityphear! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] repoman: check for deprecated eclasses
> > I like this option better than sticking another file into the public > > tree that no user will ever need. > > Instead, modifying the eclass metadata and adding two new keys, that > users will never need is fine? :) > > This isn't really user data, tiz developer data; thus the user bit > doesn't matter. Sarcasm aside, what *does* matter as that the > purpose of this is a temporary hack to cover portages ass. In light of it being useless data for users is there any reason not to add the files to CVS and then pull them out before the tree is synced with the master mirror as part of that script? --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for September
On Fri, 2006-09-01 at 17:08 -0700, Robin H. Johnson wrote: > On Fri, Sep 01, 2006 at 05:51:07AM +, 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) ! > Is this the new council for which the voting should have just ended, or > the old council? Polls for the council close at 00:00 UTC September 11th, they didn't open on Aug 1st. As such it will be three days after the polls close so it should be the inaugural meeting of the new council. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Democracy: No silver bullet
On Thu, 2006-08-24 at 17:26 -0400, Michael Cummings wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stuart Herbert wrote: > > We've had a global vision for where Gentoo is going from before I > > joined - Gentoo is here to create a source-based distribution where > > each package is as close to what $UPSTREAM intended it to be as > > possible. We're not trying to take $UPSTREAM packages and innovate > > with them - we're here to do a first class job of packaging them up. > > Um, that's a mission statement, not a vision. A vision is a series of > goals for a project, like "my vision is that we will produce knoppix > like catalyst+template releases for myth, firewalls-on-a-disk, etc by > the 2007.0 release." a mission statement is "we'll make the best from > source distro ever." i.e, mission statements never change because they > are just an overarching definition of a project, not the vision or goal > it might be working towards at the moment. > > somebody shoot me, my job in middle management is finally getting to me. Exactly... Above and beyond that is the next step...once you have a vision...ok so what do we need to do to further the vision, do we need more devs doing X, do we need hardware Y, do we need an Ice Cream machine... Leadership is way more then just shouting a vision out to the world and expecting people to hop to it...its about helping facilitate that visions completion, keeping yourself involved so those working on it feel involved themselves...leadership is just as much a community building exercise as any of the rest of it. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Democracy: No silver bullet
On Thu, 2006-08-24 at 20:55 +0200, Thierry Carrez wrote: > Lance Albertson wrote: > > > Anyways, I'm not going to take any more flame bait since I'm sick and > > tired of this shit. > > And my intention was not to revive that precise debate. I'm just saying > that for the "leader" (or "strong council") to succeed, everyone has to > follow what he/they decide. > > With the current organization/devsgroup, very often the affected team > will think that the decision is not right or could be improved (and very > often they will be right, as they know better their turf than anyone). > Is *everyone* here prepared to obey to orders they won't like ? > > That's why I agree with you Lance when you say : > > > I'm afraid those days are in the past unless some kind of fork happens > > where the folks who think we need a leader go their way and the folks > > who prefer the leader-by-committee approach go their way. We all hate > > forks, none of us have time for forks, but looking at the dividing line, > > I don't see how we'll be able to compromise with out adding more > > policies and BS. > > I've done my best the last two years trying to change the metastructure > into something more efficient. I guess I failed. A lot of current devs > did not enter Gentoo by signing a "I will obey to the leader" paper, so > they decided noone can rule (or change the system). I see only a fork to > solve the division between those wanting strong leadership/vision and > those wanting gentoo-dev votes for every decision (yes, someone asked > for that not that long ago). The way I look at it is having strong leadership does not mean abdicating your ability to provide quality input in the leadership process. The entire reason for the two aforementioned issues boiled down to a lack of communication. I believe that the job of a good leader is to seek out feedback from those that know better about an issue then they do. Being a good leader *means* understanding your strengths and weaknesses. Taking the email issue previously mentioned as an example. The council was under the impression that since the discussions happened out in the open that any issues anyone had would have been raised in that forum, infra was under the impression that if they were going to be asked to perform a new duty that their opinions would have been actively solicited (and I'm talking more then "Well the meeting agenda was posted and no one from infra showed up ... I guess infra doesn't care.", what I am talking about is "Well this involves infra in a key way, lets get Lance and Kurt in here to discuss this and if we can't find them lets postpone the discussion until we can."), neither happened and what we ended up with was an edict that made no sense. Clearly, although filling this role is less then glamorous, the roll of those in charge has to include actively tracking the involved parties down, quiet acquiescence and silent acceptance can't work when dealing with issues that involve the hard work of other people. When I talk about strong leaders who provide a forward looking vision I am not talking about people who do this in a vacuum, I am talking about people who coalesce the will of the group into a cohesive plan and provide way points along the way to ensure that progress is being made. I am talking about people who build their own vision on top of the ideas of the other groups that make up the community. Sure even in those cases there will be conflicting goals and differing opinions but those in charge should be able to hear those out and try to come to a rational compromise. From there the decision has to stand...I have a feeling that following a plan, even when it doesn't jive with your view, will be an easier pill to swallow if you are sure that your input and concerns were honestly heard and digested as part of the decision making process. I think of the community as a whole as a sort of advisory board to the Council...I dunno, I'm sure there will still be those that are so upset that their choice, opinion, or plan was not heeded 100% that they throw a fit and/or leave but maybe just maybe that is OK, maybe that is just a sign that was they want isn't what Gentoo is. We are trying to make Gentoo everything for everyone and failing...maybe we just need to accept that we are not and cannot be and that people moving on to find what really is what they want is healthy, not only for Gentoo but for Linux and OSS as whole. --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Democracy: No silver bullet
> If I could go back in time a couple of years and prevent this democracy > from ever happening, I would. If I could fix these problems myself, I > would. But it requires buy-in from the entire Gentoo community if we're > to do anything about it. First of suffice it to say that many a time in the past (and that is sad to say as I have only been a dev for just over two years) I have been privy to whispered murmurs that happen in back rooms behind closed doors. These whispers have always come about when one of the aforementioned log threads have come about and the penultimate conclusion of every one is that the problem that Gentoo presently faces is in fact too much freedom. Part of me wants to believe that you are right in that the only way to get back to a place where there is true vision and power behind the Gentoo name is to get community buy in and part of me wants to hunker down and accept the likely reality that the only way to get back to a point of health is to start laying the "smack down". Now I don't mean to say that there is any negative connotation to that process...just that those that are elected to be in charge are inherently trusted to do their best for the future of Gentoo and that implicit in that trust is an understanding that they may have to take dirty and potentially unpopular roads to maintain that health. Bitching and complaining be damned; part of what paralyzes us is an acquiescence to that vocal minority. None of us want to deal with hearing the outcry so no-one does what is needed. Basically I'm saying that while some level of acceptance has to come from the community as a whole and some level of it has to come from the top down whatever the outcome. The Council has to be willing to be the body whose job is to maintain the long lasting heath and happiness of the developer community, that community is what Gentoo is. In addition to the conclusion that too much freedom has entered the life-blood that drives Gentoo it is also often the case that from the stance of upper management there is not enough freedom given. Part of what paralyzes the Council and devrel and any other historical body that has tried to keep Gentoo healthy is that there is an understanding that they can only act as a whole...as individuals none of them have power as there is fear that a rouge person in a position to abuse their responsibility will do so. It is my contention that with a body of multiple individuals such as the Council that there would be the ability to recognize and mitigate the damage done by such a rogue. I'd posit that by voting someone onto the council you are saying that you trust them enough to carry this duty on their shoulders. The Council itself should not be just a technical body to validate the merits of GLERs and/or emerging projects, it (or some other yet to be established group) has to carry the solemn duty of carrying Gentoo into the future, nurturing it as only a parent could. I'd also wager that allowing those who have been trusted to be in power to act a little on their own would provide the capability for that group to react more quickly, there wouldn't need to be emergency meetings, you wouldn't need to push off decisions for a full month and in general as there would be more activity there would also be more transparency as the actions of the group would be visible. All in all I suppose that is the platform that I am running on for this years Council...take it for what you will but that is where I stand. Thanks, --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
> 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, --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
After mulling it over for a bit I think I could actually do some good here. Plus another name in the hat makes the elections that much more interestingas my campaign pledge I promise to establish a developer juice bar (I tried for the ice cream machine but the lactose intolerance lobby is just too powerful), to extend developer vacations to include alternate Thursdays, and to establish National Larry The Cow Day...my people are still talking to the small transgender cow lobby to pinpoint the exact day/month...you'd be surprised sexual presentation is not the only thing that transgender cows have a hard time making their mind up about. The long and short of it...I accept. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Defining the Tree: a proto-GLEP.
On Mon, 2006-06-12 at 19:04 -0400, Luis Francisco Araujo wrote: > Stephen Bennett wrote: > > Continuing in the series of issues raised during the previous package > > manager discussions, I'd like to continue by mentioning the tree > > format. At present, it isn't defined beyond "what the current portage > > supports", which is frankly a fairly silly way to do things. Following > > discussion in #gentoo-portage, I'd like to set out to change that. > > > > My current idea is to draw up a formal specification of what ebuilds > > are allowed to do, and what to assume about the environment in which > > they run, as well as defining the formats of everything under > > profiles/, metadata.xml files, and other auxiliary information in the > > tree. I would envision the first version of this document to more or > > less codify existing practise, perhaps excluding some dubious tricks > > that are known to break in some cases. Generally, it should be possible > > to make the tree conform to the first version of the specification by > > changes no more significant than currently have QA bugs filed for them. > > > > It seems fairly obvious that any effort of this kind could potentially > > have implications, albeit hopefully very minor, across more or less all > > aspects of the tree, and so I'd like to seek as wide a range of input > > as possible before going ahead with it. The QA and Portage teams, based > > on my enquiries in IRC, seem broadly in favour, and I would imagine > > that this could be very helpful to Gentoo/ALT as well, so I'd like > > opinions from others at this point. Would you support such an effort, > > whether passively or actively? Would you oppose it? If so, why? Final > > implementation of it would I assume require the Council's approval; > > while I won't ask at this stage for a formal discussion I'd appreciate > > the views of its members on whether such an initiative is likely to > > pass. > > > > Any input is gratefully received. > > > I like the idea. This would be some kind of portage-tree standard? It's been one of the missing cornerstones of the whole equation. Lets get it done and get it done right. One thing I do ask...Lets all start now getting used to calling the "portage tree" something different. I'm all for terms like "the tree" or "the ebuild tree" or "the package tree" but at this point, given the prompting subject matter, the idea of it being a tree which belongs to portage seems outdated. This may seem like a small thing (like the teams vs. herds argument that has been brought up countless times before) but it is the silly little things like this that really do lower the mental bar for new and exciting things to happen. Thanks, --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise -- Proposal
Comments inline ...
On Sat, 2006-06-10 at 13:37 +0200, Markus Ullmann wrote:
> Okay, so after figuring out open problems (thanks to kloeri and various
> other people for help here), we now have a resolution that should
> satisfy all involved parties here. This should adress dostrow's demands
> as well.
>
> 1) m-w / m-n requirement
>
> Only ebuilds that are reported to bugzie (valid bug#) and set to
> maintainer-wanted are allowed here as well as maintainer-needed ones.
>
> maintainer-needed are only allowed if they're removed from the tree and
> moved over to sunrise (and thus end up as maintainer-wanted again).
Fine.
> 2) Not one large tree but subdirs, one per herd
>
> to help herds better keeping track of which parts are alive in the
> overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be
> a netmon/ dir with net-analyzer/specialapp below it.
Fine.
> 3) a yes from herds required, keeping a timeout to avoid bugspam
>
> after a comment has been placed on a maintainer-wanted bug in bugzie,
> there's a grace time of two weeks for herds to either leave a comment on
> whether they're fine with take over or not. When this time is over and
> it is assigned to maintainer-wanted, then and only then it is implied as
> an OK to keep it also in the sunrise project.
I'm 100% against implicit acceptance. If someone from the sunrise
project wishes to add an ebuild to the overlay they should have to get
an explicit OK from the team in question. The sunrise project could of
course keep a list of teams that have given a blanket OK and of those
that have totally opted out. For those teams in between an OK per
package sought by the sunrise project's team members is needed. I'm
sorry but the leg work to track this stuff and get acceptance has to be
100% on your projects head. Your proposal adds a need for me to actually
look at bugs for packages that I may have no interest in. I don't pay
any attention to maintainer-wanted now I don't want to pay any attention
to a subset of that ever.
> 4) work needed by herds
>
> - take a look at the homepage of the new program
> - take a look at the ebuild
>
> If you're at least partly happy with the new app, drop a note on the bug
> or just ping sunrise that you're ok with it. Then sunrise takes it over
> and improves the ebuild together with the contributor so that it reaches
> a level where it could theoretically be committed to the tree.
> Herds are more than welcome to help here if they feel like it but basic
> checks whether the app should ever be on gentoo will be sufficient.
So long as this is voluntary and the level of acceptance that I
described above is met I'm OK with it.
> 5) commit access to the overlay
>
> We implement two levels of commit rights:
>
> 1. As there are people out there who just want to maintain one app for
> start, the ebuild should reach a level that project devs are fine with
> it, then the user is given permission to commit on that single app. An
> automated check makes sure that he doesn't commit anywhere else. If
> violations arise, the access is revoked immediately.
>
> 2. People who contribute good ebuilds over a certain period of time are
> allowed upon decision by project devs to actively help maintaining the
> project. They'll be given commit rights for the project then. Same frome
> above applies here: If we notice any abuse, we revoke access immediately.
Again so long as the team that would have to maintain it in the tree
says OK *explicitly* then sure.
> 6) QA assurance
>
> Of course there are minor issues with the ebuilds, otherwise they could
> be committed straight forward. Important thing is that it only finds the
> way into overlaye if the trusted committers (project devs and users who
> are given permission explicitely, see above) are fine with it.
> Additional note on arch issues: initially, just ~x86 and ~amd64 may be
> set. The rest would need successful test reports for other ~arch
> keywords. Stable keywording isn't permitted at all, there will be some
> automated check to make sure no one does it (by accident) here.
>
> Additional note: we won't start adding this to layman and making it
> available easier until the QA checks have been implemented.
Erm...no! See that is the thing about item #1 on my list...there is
nothing preventing Joe User from checking out the overlay and adding say
a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs
*will* be generated for arch teams for packages that are not in the
tree.
Also note I'm not talking necessarily about the "Hey, I installed
${package} and it broke." bugs because if ${package} isn't in the tree
bug-wranglers can catch it and off you go...the arch teams aren't
involved. What I am talking about is "Hey, my ppc64 started doing weird
things yesterday, ${daemons} are no longer working." having that bug
assigned to the arch team, and then spending a long time only to track
down that the user installed some random library from s
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
On Fri, 2006-06-09 at 14:46 -0500, James Potts wrote: > On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote: > > > Markus Ullmann wrote: > > > > Maybe that way we avoid any misunderstandings, nearly doubled posts and > > > > repeating ourselves over and over again. > > > > > > The problem is that some questions and answers easily get lost in a > > > mailing > > > list. To solve this shortcoming, I am starting to make a FAQ page in the > > > trac wiki: > > > http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq > > > > > > We are adding new questions there, if you have some additions, please talk > > > to me and I will add them for you. > > > > I have one... > > > > What will it take for this project to go away? > > > I have a counter-question to this: What modifications to the sunrise > (not sunrice, btw) project would have to be made to get you to stop > actively trying to shut it down? I really don't care if you think the > team will be willing to make the changes, list them anyway, please. :) > > I'm asking because I think that this project is a Good Thing, if it > gets handled correctly. I also agree that if it is not handled > correctly it can and will be a Very Bad Thing. To start with (and mind you this is just my list): 1). At least one member of the project must be familiar enough with each of the officially supported architectures, x86, amd64, ppc, ppc64, hppa, alpha, mips, sparc and ia64, to support any bugs which arise due to arch specific issues. The level of knowledge must be on par with that which is required to join any of the aforementioned arch teams. This is the only way to ensure that arch teams do not experience a higher work load because of this overlay's existence. 2). For a package to be added to the overlay at least one member of the project must be familiar enough with the package that they would be accepted into the team that would maintain the package if it were in the mainline tree if they are not already a team member. This is the only way to ensure that non-arch teams do not experience a higher work load because of this overlay's existence. 3). Teams must have the option to "opt-out" of participation. What this would mean is if a team "opts-out" no packages may be placed in the overlay that would be maintained by said team if the package was added to the main tree. 4). Packages cannot be added that are version bumps or bug fixes of packages that are already in the tree. 5). The project must have an active security liaison who's job it would be to ensure that there are no packages in the overlay that have outstanding vulnerabilities. 6). The project must have an active QA liaison who's job it would be to ensure that *all* of the QA standards that are applied to the main tree are also applied to the projects overlay. And the above is just the tip of the iceberg...but satisfy those and I'll give you the rest. The next thing I'll hear is "But this is really no different then hosting them on Bugzilla except it lowers the bar for their use..." Which brings me to my next point...like it or not the lower the bar for their use the more generally accepted the idea that using the ebuilds in this overlay is "officially supported". --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
> Peper wrote:
> >>> well. A couple of examples:
> >>>
> >>> http://bugs.gentoo.org/show_bug.cgi?id=122500
> >> And again, you use my project of an example. Perhaps you should try
> >> looking at something that actually supports your argument?
> >
> > I think it's an example of how user-friendly is bugzilla...
>
> Yeah, exactly... I don't understand where did this idea of me using
> someone else's own project against himself came from in the first place.
> *confused*
>
> I've merely posted a few examples illustrating that bugzilla and
> attachments suck big time for new ebuilds' development. Or, why did you
> switch vmware-server work to SVN if bugzilla is *the* place for all
> this? Apparently it's not all that great, otherwise you wouldn't have
> done that.
>
See you are just missing the point. He switched it to a VMware specific
SVN repo maintained by people who know VMware inside and out, otherwise
known as the VMware team. There is a HUGE difference between an overlay
with ${random_ebuilds} maintained by a small group who cannot possibly
know all of the ins and outs of every package and their impact on every
architecture and a targeted overlay for a very specific purpose which
only contains ebuilds for which the maintainers have 100% complete
understanding. Targeted overlays maintained by people who understand the
packages in question in totality == good, Catchall overlays maintained
by a few people who cannot possibly (and this isn't meant as a dig
against anyone it's just a fact) understand the implications and
interactions of *all* the packages in said overlay == BAD!
--Dan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paludis and Profiles
> Your claim, specifically, was "It *is* essential if paludis were to > ever be used for release building.". There is more than one way to skin > a cat, and some of those ways don't involve getting blood all over the > floor. Unfortunately in this case there is only one cat, he has only one skin and there is only one knife with which to skin him. Chris asked if paludis can build a release (meaning an official Gentoo release), which means following the Release Guidelines to the letter. That involves things that you clearly state that paludis either cannot or will not do. Your answer boils down to "Paludis can (or will be able to) build something that would work in a similar fashion to an official Gentoo release insofar as it has the ability to facilitate an end-user install. It does not now nor will it ever be able to create a release according to the Release Guidelines." In effect making your answer "No." --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] overlay support current proposal?
On Friday 24 March 2006 15:06, Daniel Ostrow wrote:
> On Friday 24 March 2006 14:35, Grant Goodyear wrote:
> > After reading through that fairly lengthy thread, I'm afraid that I can
> > no longer tell exactly what is being proposed. Who has read access?
> > Who has write access? Bugs are handled where, and by whom? Are we
> > considering a fairly tightly controlled system, or a wild free-for-all?
> > Exactly which problem are we proposing to solve here?
> >
> > If someone could succinctly summarize the current schools of thought,
> > I'd be quite indebted.
>
> As I understand it...
>
> o.g.o would be used to host developer and team based overlays that are
> owned an operated by existing Gentoo devs. Users would not be able to
> create their own overlays hosted on this system. The developer(s) who own
> the overlay would be able to control the granularity of access ranging from
> developers only, to developers plus a few trusted users, to full public ro
> access.
>
> As far as I read it, who handles the bugs and by what means at this point
> is still up in the air as there seem to be some groups that would rather
> handle bugs through their own mechanisims, be that IRC, e-mail, trac
> whathaveyou and those that would like to be able to track bugs through
> bugs.g.o.
>
> There is also the question of limiting the number of 'false' bug reports
> based uppon overlay usage, it seems that the best way to work through this
> is by augmenting the output of emerge --info. Things like a list of
> overridden eclasses in the output and the capability to add a package as an
> arguement to emerge --info in order to see if it is coming from an overlay
> seem to be good starting points.
>
> On a less technical note there is also the question of using the o.g.o
> frontpage as a means to point to existing repositiories of user created
> overlays in order to promote them.
Forgot one thing...
Even if an overlay doesn't have public access it's existance and a full
Changelog would be available via the o.g.o frontpage to allow interested
parties to contact the developer(s) who own the overlay to get involved. This
would allow things like the Haskell overlay the ability to keep a small list
of trusted contributers and promote the overlays existance to other potential
users and developers.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpgfjZTVFISU.pgp
Description: PGP signature
Re: [gentoo-dev] overlay support current proposal?
On Friday 24 March 2006 14:35, Grant Goodyear wrote:
> After reading through that fairly lengthy thread, I'm afraid that I can
> no longer tell exactly what is being proposed. Who has read access?
> Who has write access? Bugs are handled where, and by whom? Are we
> considering a fairly tightly controlled system, or a wild free-for-all?
> Exactly which problem are we proposing to solve here?
>
> If someone could succinctly summarize the current schools of thought,
> I'd be quite indebted.
>
As I understand it...
o.g.o would be used to host developer and team based overlays that are owned
an operated by existing Gentoo devs. Users would not be able to create their
own overlays hosted on this system. The developer(s) who own the overlay
would be able to control the granularity of access ranging from developers
only, to developers plus a few trusted users, to full public ro access.
As far as I read it, who handles the bugs and by what means at this point is
still up in the air as there seem to be some groups that would rather handle
bugs through their own mechanisims, be that IRC, e-mail, trac whathaveyou and
those that would like to be able to track bugs through bugs.g.o.
There is also the question of limiting the number of 'false' bug reports based
uppon overlay usage, it seems that the best way to work through this is by
augmenting the output of emerge --info. Things like a list of overridden
eclasses in the output and the capability to add a package as an arguement to
emerge --info in order to see if it is coming from an overlay seem to be good
starting points.
On a less technical note there is also the question of using the o.g.o
frontpage as a means to point to existing repositiories of user created
overlays in order to promote them.
Hope that helps,
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpKBvrnkBVTM.pgp
Description: PGP signature
Re: [gentoo-dev] Official overlay support
On Thursday 23 March 2006 13:57, Jakub Moc wrote:
> Ciaran McCreesh wrote:
> > On Thu, 23 Mar 2006 19:31:24 +0100 "Stefan Schweizer"
> >
> > <[EMAIL PROTECTED]> wrote:
> > | What about if we just skip your "policies" and let the overlays be a
> > | free place where people can handle issues how they think it is right
> > | for the specific case and not how $super_dev said somewhere. That is
> > | what overlays are about, not?
> >
> > Sounds like a perfect way to break lots and lots of systems. Those
> > policies are mostly there for good reason.
>
> You want to apply policies on overlays? Well no - sorry, overlays are
> none of QA's or any other policy business. They are overlays, not
> official tree. If user installs ebuilds from overlay and breaks his
> system, then well - not a Gentoo problem. Why should any policies apply?
That is not what Stuart said, he indicated that overlays would be treated as
supported systems including the use of our bugzilla system to track defects.
If that is the case it crosses the line into the land of the "official" in
which case policys start to be applied. While I agree that it would be very
useful to have any overlays centrally located I do find the term "Official
overlay" to be insanely oxymoronic in your use of the term overlay, which I
gather to be "a set of ebuilds not bound by the QA and/or security
requirements of the portage tree".
If I understand correctly what you are pushing then is a Official overlay
respository for Unofficial overlays
You can't have it both ways, either they are wholey Unofficial and do not get
tracked in bugzilla at all (something which would have to be made VERY clear
to our users, e.g. a you use it you get to keep the pieces policy, and the
developer or team in question is the *only* point of contact for fixing
things) -or- it is an Official overlay with official support which means it
needs to abide by the rules...
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpQyEPKB2Xy4.pgp
Description: PGP signature
Re: [gentoo-dev] Official overlay support
On Wednesday 22 March 2006 12:03, Donnie Berkholz wrote:
> Stuart Herbert wrote:
> > I've been very happy with using svn+trac overlays to bridge this gap.
> > They provide a sandbox for contributions to be shared and evaluated.
> > They provide a place where I've been able to give commit access to
> > non-devs, so that they can learn the ropes w/out threatening the
> > Portage tree proper. They provide a place where people who just want
> > to write docs for a single package can contribute.
> >
> > Overlays create a sense of participation that's lacking with Bugzilla
> > patch submissions. Backed up with regular communication (I recommend
> > not recruiting anyone who won't spend time in the IRC channels, but
> > that's a personal preference), they help us get things done quicker.
> >
> > The downside with overlays at the moment is that they're scattered
> > around the net, and if you don't know where to look they can be very
> > hard to find. I've been talking with infra about providing
> > overlays.g.o as a central hosting service for herd and individual
> > developer overlays. Infra have been very supportive of the idea. I
> > just need to free up some time to get the service launched.
>
> This definitely sounds like a fun idea. It would be even cooler if we
> were using a distributed SCM on both ends that allowed for easy merging.
I agree, I'd love to see something like this, that way I could have my xfce
stuff someplace more public then my devspacethe only thing that would
have to be clear is how official the overlays actually were, e.g. how prone
the team looking after the overlay would be to accepting bugs via the usual
b.g.o channels etc.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpwacZblRAun.pgp
Description: PGP signature
Re: [gentoo-dev] Change layout of distfiles
On Monday 06 March 2006 13:18, Simon Stelling wrote:
> Daniel Ostrow wrote:
> > Hrm, /me thinks you are missing something there, almost the entire tree
> > doesn't explicitly state the mirror://gentoo SRC_URI, portage handles
> > that automatically. That being the case portage would have change so that
> > the automatic lookup was mirror://gentoo/${firstchar}/. So that is at
> > least one portage change I can think of being required
>
> Huh? What does it state then? AFAIK ebuilds should ALWAYS use the
> mirror:// URI when possible, and since this change is only affecting our
> own mirrors, it is always possible.
You seem to be missing my point, let's pick an ebuild at random, say
app-admin/cronolog whose SRC_URI="http://cronolog.org/download/${P}.tar.gz";,
no the automirror script will need to know to mirror at in /c/ on the
distfiles mirrors, that's outside of portage, however when I emerge cronolog
portage will need to know that the location, on the distfiles mirrors, of
cronolog, is now the equivilent of mirror://gentoo/${firstchar}, taking
distfiles.gentoo.org as an example that would mean
http://distfiles.gentoo.org/distfiles/c/${P}.tar.gz, that means a portage
modification in my book.
> > Sure I can still see your point about needing to manually change the
> > packages that do explicitly state mirror://gentoo in their SRC_URI, but
> > given that you would have to do the above anyway
>
> Huh?? My point was that we shouldn't have to change all those ebuilds
> but instead just changing the mirror://gentoo-mapping.
And I was saying I agree since the same work has to be done to handle all the
automirrored stuff anyway.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpCvttJt2IaE.pgp
Description: PGP signature
Re: [gentoo-dev] Change layout of distfiles
On Monday 06 March 2006 12:36, Alec Warner wrote:
> Michael Renner wrote:
> > Kurt Lieber wrote:
> >> If we can come up with a seamless, painless transition process, great,
> >> let's make it happen.
> >
> > From the _MIRROR_-side using hardlinks should be fine enough, we'd just
> > have to ensure that every mirror uses -H (preserve hardlinks). And for
> > the mirrors not using -H this will just result in increased traffic and
> > diskusage (42GB at the moment, might hurt a bit ;) ). Shouldn't be a
> > problem though ensuring that every mirror uses -H (and I think they
> > already do, since we already did hardlink magic when moving old releases
> > to historical)
> >
> > I guess the more complicated part will be adapting the ebuild system to
> > look for/store the files in the new location.
>
> Taking the earlier comment ( changing files only on the mirrors ) there
> are no portage changes that are technically required. However, you'd
> need to change about 1 ( random number I pulled out of my ass, but
> there are many affected ) SRC_URI's to point to the new format, or
> produce some sort of hack that translates between the two, and I
> wouldn't be to fond of the latter effort, mostly because it would
> probably rot in the tree for way too long ;)
>
> And you need to modify policy for placing files on the mirrors, but
> thats not a portage problem either; from the portage POV the change is
> relatively seamless.
>
> > best regards,
> > Michael
Hrm, /me thinks you are missing something there, almost the entire tree
doesn't explicitly state the mirror://gentoo SRC_URI, portage handles that
automatically. That being the case portage would have change so that the
automatic lookup was mirror://gentoo/${firstchar}/. So that is at least one
portage change I can think of being required
Sure I can still see your point about needing to manually change the packages
that do explicitly state mirror://gentoo in their SRC_URI, but given that you
would have to do the above anyway
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgppxjDgRp6ds.pgp
Description: PGP signature
Re: [gentoo-dev] QA Roles v2
pe that noone thinks the QA team is out to get them. They are
here to make the experiance better for all of us as a whole (even if
that sometimes means that the experiance for a particular package or two
needs to be a little worse). Tree QA is something that we have never had
before, at least not really (don't mean to trivialize the work that
Mr_Bones_ does). It is something that I believe we need so lets all help
with the transition instead of fighting it.
Thanks,
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpjoHYyUIVpq.pgp
Description: PGP signature
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 2006-02-26 at 22:17 +, Stuart Herbert wrote:
> On Sun, 2006-02-26 at 17:02 -0500, Daniel Ostrow wrote:
> > That would work for fetch restricted packages, not nomirrored ones.
> >
> > --Dan
>
> /me nods. That's what we'll have to do. Unfortunately, it leaves users
> with a worse experience than before, but until I can find a way to reach
> the QA team and help them see my pov as the package maintainer, what
> else can I do? :(
Don't know why this didn't occur to me before but this is exactly what
the Java team does for IBM's jdk/jre. IBM releases all micro releases
under a tarball of the same name so end users already have to rename it
before placing it in ${DISTDIR}. The only difference there is IBM's
files were already fetch restricted.
In any event, even though I'm not part of the QA team, thanks for
accepting an alternate solution.
--Dan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SRC_URI component naming collision
On Sun, 2006-02-26 at 21:54 +, Stuart Herbert wrote: > On Sun, 2006-02-26 at 13:29 -0800, Robin H. Johnson wrote: > > Simply tell the user to download X and place it in $DISTDIR renaming it > > to X-foo-bar, where's you've chosen X-foo-bar to avoid conflicts. > > That works for me. > > Best regards, > Stu That would work for fetch restricted packages, not nomirrored ones. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] SRC_URI component naming collision
> I'll contact the council separately, and ask that they look at two > things: > > a) What the QA team is and isn't empowered to do > b) The approval process that the QA team must follow before imposing > tree-wide changes on other developers. According to prior council meeting logs: 15:14 <@vapier> QA works off of agreed policy. policy was put forth by developers and validated by council. 15:14 <@seemant> the fact is, QA can scream all they want -- but if there's no *authority* behind them, devs might be inclined to feel free to ignore QA 15:14 <@Azarah> and if they do, they get sorted by devrel in theory 15:15 <@vapier> so they have authority now. listen to the QA team because they're working of valid policy. if you dont, devrel will take action. So the only question in my mind is what does it take for something to become 'vaild policy'. I believe the QA team is working on a writeup to present to the council to address that issue. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP 42 (news) Round Seven
On Thursday 05 January 2006 10:11, Ciaran McCreesh wrote:
>
> I might end up being offline over the weekend (and possibly for a while
> after that too...), but I'll get around to any feedback as soon as I
> can...
While it is entirely nitpicking at this point as I understand what you meant:
Under Client Side you clearly identify ${repoid} as a variable when used for
example in the context of ``news-${repoid}.unread``. However in the following
section, News Item Clients, you refer to ``news-repoid.unread`` and
``news-repoid.read``, I'd just throw repoid in those cases into a ${} for
people reading it that weren't involed in the implementaiton so that know
that unless the repo is actually named 'repoid' no such file will exist.
Thanks and +1,
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpFHo5aPMVVn.pgp
Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
[snip]
> Thanks for your comments.. As for management, anyone who reads "Five
> Dysfunctions of a Team" by Patrick Lencioni[1] will see all of the problems
> that Gentoo has, as well as the potential Gentoo has if it worked well.
[/snip]
OK granted it is a shameless plug, but this book is so on point that I
finished it in one night. Not to say that that is any major accomplishment
it's a pretty short book. But it basically lays out in black and white what
is wrong with the way things are, and what could be done better. It really
was rather frightening how very much like Gentoo the small 'Board of
Directors' in this book is.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpD27FoRXXBc.pgp
Description: PGP signature
Re: [gentoo-dev] mac/xmms-mac licence issue
On Sat, 2005-12-24 at 19:35 -0800, Bret Towe wrote:
> On 12/24/05, Ciaran McCreesh <[EMAIL PROTECTED]> wrote:
> > On Sat, 24 Dec 2005 19:17:05 -0800 Bret Towe <[EMAIL PROTECTED]> wrote:
> > | On 12/24/05, Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> > | > This isn't politics, but copyright infringement on top of a
> > | > ridiculous license (when you want to see it as one) we had a short
> > | > discussion¹ about several months ago.
> > |
> > | im sorry i fail to see how copyright infringement or a ridiculous
> > | licence matters when commiting a ebuild to portage just pick a
> > | licence if thats the issue warn the user and leave it at that
> >
> > Would you like us to add the Windows XP source code to the tree with
> > LICENSE="gpl-2" as well?
>
> whats the point i cant get the same crap from /dev/random
>
> sarcasm aside considering its just an ebuild that points to the source
> which could be not hosted on gentoo mirrors and the LICENCE bit
> is to notify the user ahead of time what the licence is and,
> assuming the functionality was there, allow said user to ignore
> all applications that use that licence type but since that isnt there
> it could be anything and it doesnt really matter now does it?
Read my last e-mail, it is a question of culpability do to the
facilitation of an illegal act, a crime in and of itself, nothing more,
nothing less. Sure we wouldn't be shipping the actual source, but what
we would be doing is facilitating your use of said source, which is
*illegal*.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] mac/xmms-mac licence issue
On Sat, 2005-12-24 at 19:17 -0800, Bret Towe wrote:
> On 12/24/05, Carsten Lohrke <[EMAIL PROTECTED]> wrote:
> > This isn't politics, but copyright infringement on top of a ridiculous
> > license
> > (when you want to see it as one) we had a short discussion¹ about several
> > months ago.
>
> im sorry i fail to see how copyright infringement or a ridiculous licence
> matters when commiting a ebuild to portage just pick a licence if thats the
> issue warn the user and leave it at that
What you are missing is that Gentoo (the foundation) is legally culpable
for making sure that none of the packages that we provide in our tree
violate any form of license. If we shipped these e-builds then the
original author would have the legal right to take action against us. It
is not just a question of letting the user decide if they want to use an
illegally licensed program, we would be facilitating such an act. That
is something we cannot and will not do.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Update of http://wwwredesign.gentoo.org
On Wed, 2005-11-23 at 01:40 -0500, Curtis Napier wrote:
> Accessibilty guidelines say that all text links should be underlined. I
> made an exception for the grey menu bar for aesthetic purposes but will
> not make an exception for any other links.
Given the above shouldn't the text links below each advertisement
graphic also be underlined. The implication of the current text is that
they are not links at all when they are.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] R/O CVS access and its purpose for ATs (was Email subdomain)
On Tue, 2005-11-22 at 17:56 -0600, Lance Albertson wrote:
> Marius Mauch wrote:
> > On Sun, 20 Nov 2005 09:32:55 +1100
> > Ben Skeggs <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Anyway, the most important reason for the GLEP (IMO) is giving AT's
> >>r/o access to CVS. When working on bugs, it's always fun to find out
> >>that the problem has already been resolved and just hasn't made it to
> >>your local rsync mirror yet..
> >
> >
> > Out of curiosity, what's the more important aspect of r/o cvs:
> > - more up to date
>
> Not necessarily true. We would not have the anon cvs access from our
> primary cvs server. It would be synced on a regular basis to a separate
> box. The newer cvs (which isn't on lark yet) may give us capabilities to
> have a more 'live' cvs anon system. But as of now, the best infra can
> provide is 30 minute updates. I don't want to poll the cvs more than
> that to keep down the load.
>
> > - easier selective updates
>
> Yup, that's definitely a plus.
>
And herein I think lies some confusion. Personally if I were an AT both
would be important but more to the point the "more up to date" issue
would be the most important. I think that there is a need for the ATs to
be able to work in direct conjunction with a dev, an AT catches an
error, a dev fixes it in CVS using a *well tested* patch, an AT does a
`cvs up` and retests to try and catch *other* errors all within a matter
of *single digit* minutes. This is a very powerful tool, rather then
what they have to do now which is either wait for it to hit the rsync
mirrors, a dedicated rsync mirror, a dedicated anoncvs box, or e-mail
the ebuilds (and patches) back and forth. Note the two highly stressed
things up there...this should not be used so ATs can vet patches (wither
to ebuilds or to source), the patches should be well tested long before
they reach our tree...
Lance:
I know this is a far cry from what you are proposing, and I understand
that the present CVS server cannot handle this sort of load but I
believe that this was the original intention at least...someone correct
me if I am wrong.
I think that this issue has to be nailed down *before* we get any
further in discussion.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Decision to remove stage1/2 from installation documentation
On Tue, 2005-11-22 at 12:03 -0600, Grant Goodyear wrote:
> Chris Gianelloni wrote: [Tue Nov 22 2005, 09:15:27AM CST]
> > > Well, if we could educate the users that stage2 tarballs are totally
> > > pointless, and that running bootstrap.sh followed by emerge -e system
> > > from a stage3 is pretty much *exactly* the same as starting a stage1
> > > from scratch...
> >
> > It isn't pretty much anymore. It *is* exactly the same.
>
> I keep hearing this, isn't there a real difference between a stage 1 and
> a stage 3 install inasmuch as somebody who needs (or wants) to
> dramatically tailor what's in the system profile can choose to do so
> from a stage 1 or 2, but would have to remove packages after the fact if
> starting from a stage 3? I wouldn't have a problem with that, as long
> as we document it, but it just seems that the claim that the old and new
> methods produce _exactly_ the same results seems to be stretching things
> a bit.
>
> -g2boojum-
There are 3 purposes to a stage1/stage2 install (note all 3 can be
achieved with either a stage3 or a custom rolled stage though catalyst):
1). Modify the bootstrap.sh script to change what the "stage2" target
produces.
2). Modify the system target to change what the "stage3" target
produces.
3). Modify the CHOST/CFLAGS/USE et. al. early on to create a customized
and largely unsupported (things like hardened, uclibc, and embedded are
exceptions to the unsupported rule) "stage3" target.
#3 is where the vast majority of user created bugs occur. The purpose of
highly encouraging users to start with a stage3, by making the handbook
only refer to it, is to make sure that users have a known working
configuration to start their customization from. There are many many
ways to mess up going from a stage1 to a stage3, there are fewer ways to
mess up customizing and recompiling a system that has already been
configured to boot on it's own.
By and large most users will never want to do any of the above for the
reasons that they are really valid for, and any user or developer that
does will have access to both the stages (with relocated documentation)
and catalyst itself to make their own. We are not removing choice
here...just *potentially* making someones initial download time longer.
Personally I wouldn't be at all opposed to moving the stage1 and stage2
tarballs to another directory on the mirrors (documented of course),
just to make it that much clearer that if you start from a stage1 or a
stage2 RelEng won't support you if any errors occur during system build.
If RelEng ever does get to the point of removing stage's 1 & 2 from the
mirrors (something that has been discussed but isn't on the table at all
right now) end users and developers alike will still be able to generate
them on their own using catalyst and the provided spec files...sure it
is an extra step and all but it's not all that huge...
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting Tuesday, November 15th, 20:00 UTC
On Tue, 2005-11-08 at 17:57 +, Ciaran McCreesh wrote:
> On Tue, 08 Nov 2005 17:30:02 +0100 Thierry Carrez <[EMAIL PROTECTED]>
> wrote:
> | The November Gentoo Council meeting will be held on #gentoo-council
> | next week, Tuesday, November 15th, 20:00 UTC, presided by Seemant
> | Kulleen.
> |
> | The deadline for submitting items for the meeting agenda is set to
> | Sunday, November 13th, 20:00 UTC.
>
> Assuming there aren't any further comments between now and then, I'd
> like GLEP 34 (GLEP File Hosting) to be approved please.
>
I assume you meant 43 yes?
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
On Mon, 2005-11-07 at 14:02 -0500, Daniel Ostrow wrote:
> [snip]
>
> > After going through the list, I got the impression there is simply no
> > place where such messages clearly would go. gentoo-announce sounds as
> > the best option to go for, but its description somehow suggests not.
> > Though, subscribed to gentoo-announce means you get nothing but GLSA
> > announcements and sometimes a new release announcements.
> >
> > So, what list should the user that wants to receive those **important**
> > messages sign up to?
> > I still think that *this* is the reason why people don't seem to know
> > about the important changes, because there is no obvious place where to
> > get them. It's quite likely that a user that wanted to see the
> > new-style apache message didn't see it because it simply didn't appear
> > on a list the user hoped to see it. It was in the GWN of 2005-09-12,
> > but I can imagine a user didn't expect it to be there, as there is no
> > description at al for GWN list, and the **important** information will
> > always have to be extracted from the GWN, since each GWN covers multiple
> > items in a few categories which not every user might interest.
> >
> > Send **important** messages separate to a non-discussion mailing list,
> > and I'm sure that many people will be happy to read it -- just like
> > gentoo-announce.
>
> [/snip]
>
> Above and beyond Ciaran's point...
>
> You are correct, there is no clear cut place for them to go...that's how
> this thing got started in the first place. However why force users to
> sign up for something which can't be appropriately filtered (installed
> packages, keywords, use flags, profiles, etc.) when all of them are
> already "signed up" for something that can track and filter, portage.
>
> I wouldn't necessarily bother signing up for an errata list if said list
> was going to provide me with *all* the errata out there. The reason that
> a mailing list works for RedHat is because RHN tracks what packages you
> have installed on your system on *their* server (again something you
> have to sign up for, and worse send them info about your configuration),
> so the filtering is done for you. We will *never* do something like
> this, we have a client side tool that can identify what is installed
> already...why not use it?
Err...sorry for the double post...mail client error.
Oh...and before anyone goes nuts...note I said "why force users to sign
up" to such a list *not* "we will not provide such a list".
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
[snip]
> After going through the list, I got the impression there is simply no
> place where such messages clearly would go. gentoo-announce sounds as
> the best option to go for, but its description somehow suggests not.
> Though, subscribed to gentoo-announce means you get nothing but GLSA
> announcements and sometimes a new release announcements.
>
> So, what list should the user that wants to receive those **important**
> messages sign up to?
> I still think that *this* is the reason why people don't seem to know
> about the important changes, because there is no obvious place where to
> get them. It's quite likely that a user that wanted to see the
> new-style apache message didn't see it because it simply didn't appear
> on a list the user hoped to see it. It was in the GWN of 2005-09-12,
> but I can imagine a user didn't expect it to be there, as there is no
> description at al for GWN list, and the **important** information will
> always have to be extracted from the GWN, since each GWN covers multiple
> items in a few categories which not every user might interest.
>
> Send **important** messages separate to a non-discussion mailing list,
> and I'm sure that many people will be happy to read it -- just like
> gentoo-announce.
[/snip]
Above and beyond Ciaran's point...
You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already "signed up" for something that can track and filter, portage.
I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: GLEP 42 "Critical News Reporting" Round Two
[snip]
> After going through the list, I got the impression there is simply no
> place where such messages clearly would go. gentoo-announce sounds as
> the best option to go for, but its description somehow suggests not.
> Though, subscribed to gentoo-announce means you get nothing but GLSA
> announcements and sometimes a new release announcements.
>
> So, what list should the user that wants to receive those **important**
> messages sign up to?
> I still think that *this* is the reason why people don't seem to know
> about the important changes, because there is no obvious place where to
> get them. It's quite likely that a user that wanted to see the
> new-style apache message didn't see it because it simply didn't appear
> on a list the user hoped to see it. It was in the GWN of 2005-09-12,
> but I can imagine a user didn't expect it to be there, as there is no
> description at al for GWN list, and the **important** information will
> always have to be extracted from the GWN, since each GWN covers multiple
> items in a few categories which not every user might interest.
>
> Send **important** messages separate to a non-discussion mailing list,
> and I'm sure that many people will be happy to read it -- just like
> gentoo-announce.
[/snip]
Above and beyond Ciaran's point...
You are correct, there is no clear cut place for them to go...that's how
this thing got started in the first place. However why force users to
sign up for something which can't be appropriately filtered (installed
packages, keywords, use flags, profiles, etc.) when all of them are
already "signed up" for something that can track and filter, portage.
I wouldn't necessarily bother signing up for an errata list if said list
was going to provide me with *all* the errata out there. The reason that
a mailing list works for RedHat is because RHN tracks what packages you
have installed on your system on *their* server (again something you
have to sign up for, and worse send them info about your configuration),
so the filtering is done for you. We will *never* do something like
this, we have a client side tool that can identify what is installed
already...why not use it?
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] GLEP ??: Critical News Reporting
On Fri, 2005-11-04 at 12:08 -0500, Nathan L. Adams wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chris Gianelloni wrote:
> >
> > Yeah, see, this is a case where not understanding the structure of
> > Gentoo gives you the wrong impression. The GDP's policy applies to the
> > GDP. That is not a global developer policy of any kind. It is a policy
> > by a project, for that project.
> >
> > If I were, for example, to write up a nice guide for something on the
> > games team and do it all in ASCII art, that policy has no bearing on
> > what I do. If I were to write something for the GDP, then it would.
> >
> > At any rate, that has *zero* bearing on whether or not our update
> > information needs to be written in GuideXML, so there's no point in
> > arguing it with you.
> >
>
> So you're saying that Gentoo consists of projects that are completely
> 'silo'd up' and have no bearing whatsoever on each other. Then the
> DevRel project only has bearing on those who actually join DevRel. Neat,
> a group formed for the sole purpose of coordinating itself. Security
> need only concern itself with securing its members (from who knows
> what!), and infra can just ignore the needs of everyone else (different
> project!). I wonder how any of the other projects *ever* made it onto
> the website...
Yet more proof that you don't understand what you are talking
about...not meant to be insulting just stating that you don't. Just
because some groups (DevRel, Infra, etc.) have farther reaching tendrils
doesn't mean that every group does.
For example, each arch team has a slightly different way to go about
allowing package maintainers to keyword their own packages on a given
arch...some teams insist that the maintainer join the arch team...some
allow for special arrangements (they all follow the same basic
guidelines).
With documentation there are actually 2 different types, those bits that
fall under the GDP and those that fall under the herd that uses them.
Take Chris' games example, the games team is free to release an FAQ in
plain text in Pig Latin if they want to, so long as it is on their own
project page. The GDP policy -only- covers the GDP...not anyone else, so
if Chris wanted to move his plain text Pig Latin doc to the official
Docs repository he would have to make an English version and make it
GuideXML. That's it plain and simple.
> The errata.g.o (not the summaries w/ link that emerge would output)
> would obviously be documentation, would obviously be governed by the Doc
> rules, and it would be irrelevant which staff member happened to publish
> a particular guide. If Gentoo really is as balkanized as you state, then
> it is a sad state of affairs indeed. Maybe the 'full fledged' versions
> should be GuideXML-lite or something, I'm not sure, but your argument is
> just silly.
Another thing you seem to be missing is that the GLEP specifically
separates the news from the documentation. The news or errata is just a
plain text *short* summary that something needs to be attended to. It
can, but does not always have to, link to further more detailed
*documentation*. Note then that what would go up on errata.g.o in this
case would be the *summary* (which would not necessarily be governed by
the GDP or it's policies) and *not* the full documentation. Said summary
would contain links to any relevant *documentation* which would then be
governed by the GDP if said documentation was in fact Gentoo created and
in the official Docs repository.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Fri, 2005-10-21 at 17:49 +0300, Marius Mauch wrote:
> Petteri Räty wrote:
> > Marius Mauch wrote:
> >
> > Gentoo being about choice the new package.use should come before
> > anything user set. I do not see any problem with this if it works in the
> > same way as package.mask already works. Please, enlighten me.
>
> Because package.use is implemented in a very different way then
> package.mask and currently isn't stackable at all. Adding a
> profiles/package.use that could be overridden by make.conf would require
> some nasty special casing in portage, and as we all know special case
> code is something that should be avoided. Besides that, there would also
> be the question about USE=-*, should this kill profiles/package.use
> completely?
> Short version: Implementation and semantics of profiles/package.use
> isn't much easier than extending IUSE.
>
> Marius
Hijacking this for a moment. And I fully expect to be lynched for the
following but it is something that has come up in both the amd64 and
ppc64 groups in the past.
I know it has been proposed many a time in the past but a per profile
(${PORTDIR}/profiles/default-linux/${ARCH}) package.use.mask would also
come in handy. It's a rare case...but increasingly in the world of mixed
32-bit and 64-bit environments things like java work against 32-bit
stuff *or* 64-bit stuff. This means that the java use flag will work
perfectly on a given arch for one bitness but not the other...and
masking it out completely means that the one bitness where it would work
looses functionality unnecessarily.
Yeah I know this adds a whole additional layer of complexity to the
picture but seeing how DEPEND="!arch? ( use? ( app-foo/bar ) )" is
against policy there has to be some way to control it.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-portage-dev] allow extra info to be echod on die
On Wed, 2005-10-05 at 13:47 -0500, Brian Harring wrote:
> 2.0.51_rc4
And by 2.0.51_rc4 he really meant 2.0.53_rc4. :)
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] xfce eclass testing/suggestions
On Wed, 2005-10-05 at 02:38 -0400, Brad Cowan wrote:
> Hi,
>
> I just spent this evening working on rewriting a really poor eclass
> that I wrote a year or more ago. I would like some people to test and
> please offer any suggestions for improvement to this so hopefully it can
> get into portage with the next maintenance release. I'm not the best
> when it comes to writing eclasses so if you could help me out with any
> pointers I'd appreciate it. Here's a link to the overlay.
>
> > http://dev.gentoo.org/~bcowan/portage.xfce4/
>
Looks good to me...
Also I have all of the modular X deps for XFCE4 enumerated locally in an
overlay on my machine...which changes the deps in the eclass a tad...we
should coordinate on this before you commit it.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] "Commercial" software in portage
On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> Hi everybody,
>
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel with
> binary drivers.
>
More to the point...most of the ebuilds in question are just wrappers
for the install process...it still requires the original media (be that
physical or digital) or a key to install trust me when I say that we
aren't distributing binaries unless we have the right to do so.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] "Commercial" software in portage
On Wed, 2005-09-21 at 18:54 +0100, José Carlos Cruz Costa wrote:
> Hi everybody,
>
> If it's commercial, the company in question should (and must) allow an
> ebuild for is product, like what happens with rpms and other packages.
> Adding commercial ebuilds to portage is like tainting the kernel with
> binary drivers.
>
> Maybe a better solution comes with gensync? If companies want ebuilds,
> sure. They go to the "commercial" portage. Hell, even put a price on
> maintaining those ebuilds.
>
> Remember that are a lot of people that don't want to use that kind of
> software. There are people that doesn't have even xorg and have to
> sync all the ebuilds from portage.
This is what rsync excludes are for...there is no good reason to remove
things like doom3 and UT2k4 from the tree for the sole reason that they
are commercial packages. You don't want them...fine...exclude them.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 16:21 -0400, Aron Griffis wrote:
> Paul de Vrieze wrote:[Fri Sep 16 2005, 04:11:14PM EDT]
> > > Those should be in package.mask. ~arch is for candidates for arch that
> > > haven't yet proven themselves.
> >
> > It's often the case that those ebuilds in principle work, but there
> > are other reasons for not marking stable yet. Some packages for
> > example can have upgrade problems for stable users while being
> > stable for testing (by benefit of allready having passed such
> > upgrade problems). Masking the ebuild is not really an option
> > (causing testing users to go through unnecessary hoops again), while
> > marking stable is also no option.
>
> You're saying there's four states:
>
> package.mask
> ~arch
> ~arch candidate for arch
> arch
>
> Putting packages in package.mask isn't a hardship for testers. I'm
> not sure that's a good reason for the additional state. It's purely
> a matter of
>
> echo 'dev-util/mercurial' >> /etc/portage/package.unmask
>
> So far I find myself agreeing with Ciaran's idea in this thread.
> I don't see the point (yet) in more than three states.
His point (and it's an unfortunately valid one) as I understand it is
that our user base has been (mis)educated to avoid packages in p.mask
for fear of breaking things too badly. As such it gets an inherently far
smaller test base then packages in ~arch do.
Personally I am uncomfortable with people using ~arch as a "We didn't
get enough testing for package X, so we are putting it here for a wider
audience." mentality. That is the whole purpose of p.mask and released
independent overlays (such as fbsd and php use). Either way the use of
~arch for this purpose is really just wrong.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] first council meeting
On Fri, 2005-09-16 at 20:48 +0200, Paul de Vrieze wrote:
> On Friday 16 September 2005 20:38, Ciaran McCreesh wrote:
> > On Fri, 16 Sep 2005 19:42:36 +0200 Paul de Vrieze <[EMAIL PROTECTED]>
> >
> > wrote:
> > | Ok, I do think that we will need a way for the maintainer to indicate
> > | that the package is stable. I'd be happy to leave stabilizing out of
> > | my hands, but I wouldn't want my packages to be stabilized before I
> > | deem it stable.
> >
> > Take it out of package.mask and leave it for thirty (package-dependent)
> > days. If there is a pressing (eg security) reason for it to go to
> > stable sooner than would normally be expected, file a bug and Cc: the
> > relevant arch teams.
>
> I was thinking more like signalling that it shouldn't be stable yet, but
> shouldn't be masked either.
>
> Paul
Here's my 2 cents on this...the general rule of thumb for an arch
stabilizing a package has been 30 days in ~ with no open bugs. As far as
I am concerned this mean that if a package maintainer does not want a
package to follow these rules then indicating such is as easy as opening
a bug against the package assigned to him/herself stating so and mark it
for all arch's. That way when the arch team goes to look for bugs (and
we are all doing this right???) before marking a package stable they
will see the bug and know not to.
Hell the bug can be as simple as "Don't mark this package stable yet for
reasons x, y and z." Doing it this way has the added advantage of
letting arch maintainers know about the reasons why the package
shouldn't be marked stable so they know what they are getting into by
going ahead of the package maintainer.
Personally I like this outlook a lot better then the maint ~maint option
because it provides information and fits into present policy. All in all
it really isn't that hard to open a bug.
If the package is truly not stable then it should really be moved back
into p.mask anyway.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] crap use flags in the profiles
On Tue, 2005-08-30 at 11:24 -0400, Stephen P. Becker wrote:
> >>Is this also a good time to note that the amd64 and x86 could
> >>*easily* be covered under the same keyword? We cover a large
> >>variety of mips machines/userlands under one keyword, with
> >>differences much more significant then that between x86 and amd64.
> >
> >
> > Sorry I disagree with this, differences exists and sometimes are a
> > problem. Some package and library don't compile cleanly under amd64 arch.
> > On few but existant cases it's good to have two different archs. Not
> > even going near the analizing the differences in the profiles.
>
> So these things won't compile in a x86 chroot on a amd64 box even? I
> find that really hard to believe. Besides, close collaboration between
> folks with x86 and folks with amd64 installs can make it easy to ensure
> the same versions work on both arches (if you really want to call them
> separate arches...) Your profile argument is silly too, since both
> arches could *easily* be merged into sub-profiles in our cascading system.
>
> Besides, we have the same sorts of problems on mips, except they are
> magnified since we have a possibility of 3 different userland ABIs, on
> both big and little endian hardware. After dealing with this sort of
> stuff for a long time with *far* fewer developers and time in general,
> I'm really not impressed with your argument. You'll have to do better
> then that.
>
> -Steve
I agree that merging the two profiles is something to aspire to (see the
recent ppc/ppc64 profile merge as an example. However merging the
keywords can lead to trouble. Speaking only for ppc/ppc64 there are
times when there are very specific ppc64 compiler problems that, if we
shared a keyword, leave a large portion of the tree keyworded for
stability but in a "You can only compile this program in a 32-bit
chroot" state. I would rather make a clear cut statement that these apps
only function in a 32-bit env then give the user the impression that
they work "out of the box".
Take for example Mozilla, Firefox, and OpenOffice none of these function
on ppc64 (yet) but they function without issue on ppc. It is only within
the last few months that Mozilla even got a ~ppc64 keyword (and not
because it works, all it does at the moment is launch a window).
Just to give you an idea. Last I looked (a week or so ago) the number of
ppc stable keyworded packages outnumbered the ppc64 ones by almost 3:1.
Now some of this is just due to a lack of manpower to test all those
packages, and some of it is due to a lack of end-user interest in those
packages on the ppc64 platform but I can guarantee that some of them
also suffer ppc64 specific bugs. Until the stable list matches at least
90% I personally would be unwilling to merge the keywords. If we ever
get to that point I think the remaining packages could be dealt with on
a case by case basis when users tripped over them. After that we could
deal with new packages in a coordinated way making sure that they work
on both platforms together.
I also don't buy the argument that the user has to be educated on how to
change their ABI midstream if something breaks under one or the other on
a mainstream arch. I am of the stong opinion that things should just
work, 100% of the time. That means that for each set (ppc/ppc64 &
x86/amd64) the ebuilds have to be gone over and modified to use the
appropriate abi internally. Mips is slightly different as it is a niche
architecture with a smaller, arguably better educated in the ways of gcc
etc., user base.
I don't know what the ratio is for amd64 and x86 (I suspect far better
then ppc64 vs. ppc as the dev/user base is far larger) but I think that
it is something to move towards if the ratio is close enough even if it
means denying some functionality to one group or the other until some
bugs are solved.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: gcc-config 2.0 development
On Tue, 2005-08-09 at 15:12 -0700, Jeremy Huddleston wrote: > On Tue, 2005-08-09 at 22:19 +0100, Ciaran McCreesh wrote: > > | but I think having the xml configuration files allows a much more > > | robust configuration. > > > > How so? Using XML doesn't magically make your data files any different. > > It simply makes them much harder to parse. > > That's a matter of opinion. I see it as a way to abstract away the > configuration and utilize an existing library to handle the parsing. If > we do want to eliminate outside dependencies (which I think is an > extremely valid point and concern), then we could internally implement a > different configuration format that is easier to parse. I'd probably go > for something similar to the samba/gdm config files if we were to go > down this road: I've always been a fan of samba style config files..unlike xml they tend to be both easy to parse and are human readable. I'd far rather see this over XML. It's especially attractive as this is also the way that portage is moving (at the moment) as well. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Developer: Kathryn Kulick (GothGirl)
> Who is the other husband/wife developer team? > Well before she left and he went MIA there was Eric and Aida Sammer... > Regards, > Aron > > -- > Aron Griffis > Gentoo Linux Developer > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Conference - Call for ideas
Chris: Good to know you are going to make it, I'll be there too. :) And yes I think it would be awesome if we had a presentation on the release process. --Dan On Thu, 2005-06-02 at 09:38 -0400, Chris Gianelloni wrote: > On Tue, 2005-05-24 at 09:51 -0400, Chris Gianelloni wrote: > > On Tue, 2005-05-24 at 06:27 -0700, Peter Johanson wrote: > > > Things I'd love to hear talks on: > > > * liveCD/releng process - I have a basic understanding of catalyst, stage > > > building, whatever, but hearind the shpeel from someone involved. > > > > HA! Lucky for you none of us are on the west coast... ;] > > > > I *might* be able to make it out for LWE:SF, but it is rather doubtful, > > since I just bought a house. Other than myself, only rocket and tgall > > are in the USA, and I'm not aware of either of them going to be in > > attendance. > > Well, I guess the pressure got to me. I just couldn't take it anymore. > > I *will* be in attendance at LWE:SF and also will be around for the > Gentoo Conference. > > If anyone really wants to hear more about Release Engineering and the > release process, I'll get together a little presentation or something. > > > We're also working on catalyst 2.0, which should come out right about > > that time, which has become a near complete rewrite of catalyst, so lots > > of things will have changed. > -- gentoo-dev@gentoo.org mailing list
Re: Antwort: Re: [gentoo-dev] Gentoo could become certified for IBM Server Hardware
IBM has already been kind enough to donate some hardware to us. It has
yet to arrive at our hosting facility at OSU but I imagine that is only
a matter of time. Once the hardware is in place the ppc64 team (which is
mostly made up of IBM employees btw) will look into this further.
Thanks for the heads up.
Daniel Ostrow
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
On 12:36 Wed 04 May , [EMAIL PROTECTED] wrote:
>
> First of all there are a lot of questions to answer:
>
> - Who can do the certification?
> - What must be done to become certified?
> - What hardwaretypes will IBM offer?
> - Will the hardware stay at IBM or somewhere else?
>
> Aside all IBM customers should request support for Gentoo from IBM
> because they'll only take this serious if many customers request
> support.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] What to do with things like -fpie in CFLAGS in environment?
On Tue, 2005-04-12 at 17:59 +0200, Maurice van der Pot wrote: *snip* > If compiled with the hardened gcc profile, -fno-pie has to be specified > when compiling the tests or it will fail. Specifying -fno-pie always > will force me to disable any PIE support through configure as well. > > I tried to adapt the makefiles to disable pie themselves for the tests > only, but then I have another problem: *snip* Take a look at dev-libs/glib/files/glib-2.6.3-testglib-ssp.patch to see how solar and I dealt with a similar issue with tests and ssp. See if you can adapt it, we just forced -fno-stack-protector after the CFLAGS pulled in from the system. --Dan -- gentoo-dev@gentoo.org mailing list
