Re: [gentoo-dev] baselayout-1.11.14 stabilization
On Tuesday 20 December 2005 09:36, Mike Frysinger wrote: > since we have baselayout-1.12.x in ~arch, the new stable candidate > (1.11.14) isnt getting much air time ... can people try upgrading to > it and post any feedback they have with it ? it should mostly be a > bugfix release over 1.11.13 since we arent doing any more real features > for the 1.11.x branch ... ignoring the two releng issues (since that's a bug with both 1.11.13 and 1.11.14), any last thoughts before i do this ? i'll wait until sunday nite ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
Philippe Trottier wrote:
> Lisa Seelye wrote:
>
>> On Thu, 2006-01-12 at 00:18 +, Ferris McCormick wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On Wed, 11 Jan 2006, Lisa Seelye wrote:
>>>
>>>
On Wed, 2006-01-11 at 14:51 -0800, Robin H. Johnson wrote:
> I've been cleaning up media-fonts/ to work with modular-X, and I see a
> lot of ebuilds with stuff like this:
>for font in *.bdf; do
>/usr/X11R6/bin/bdftopcf ${font} > `basename $font .bdf`.pcf
>done
>gzip *.pcf
>
> For having 100 files in *bdf, this is so serial it's painful.
And here I was hoping Distcc would get some usage. :(
>>>
>>> Distcc gets lots of usage with modular X. But for the fonts? :)
>>
>>
>> Time for distfont? ;)
>
>
> Make this distributed tool for tar zip bzip2 and gzip and I'm in, I
> don't think it would be useful with anything else than Gigabit Ethernet.
>
> We might want to have in the make.conf 2 separate variables, one of them
> saying how many threads can be run on the machine, then How many
> threads/process across a cluster.
>
> For example, my Dual Xeon EM64T file server can do make -j4 locally,
> like in make install, make docs etc etc, But for compiling I can use
> -j20, really not useful over -j8 anyway. But the point is, it would be
> usefully to separate the load distribution on the local machine and
> cluster nodes.
As the discusison started...
I would like to be able to limit the -jN when there is no distcc host
available or when compiling c++ code, otherwise my poor laptop is dead with
-j5 compiling pwlib when the network is down
It is particular example, but being able to limit portage in some way as
total CPU, total MEM might be interesting (just nice-ing is not enough)
Kalin.
--
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
On Fri, 2006-01-13 at 19:53 +0900, Kalin KOZHUHAROV wrote: > > Make this distributed tool for tar zip bzip2 and gzip and I'm in, I > > don't think it would be useful with anything else than Gigabit Ethernet. One 2Ghz CPU can't even saturate a 100Mbit line with bzip2 as far as I can tell. Although the speedups won't be extreme it could just work. > > We might want to have in the make.conf 2 separate variables, one of them > > saying how many threads can be run on the machine, then How many > > threads/process across a cluster. > > > > For example, my Dual Xeon EM64T file server can do make -j4 locally, > > like in make install, make docs etc etc, But for compiling I can use > > -j20, really not useful over -j8 anyway. But the point is, it would be > > usefully to separate the load distribution on the local machine and > > cluster nodes. > > As the discusison started... > > I would like to be able to limit the -jN when there is no distcc host > available or when compiling c++ code, otherwise my poor laptop is dead with > -j5 compiling pwlib when the network is down As far as I can tell distcc isn't smart enough for dynamic load balancing. One could hack portage to "test" each server in the distcc host list and remove missing servers for each run - doesn't look elegant to me. > It is particular example, but being able to limit portage in some way as > total CPU, total MEM might be interesting (just nice-ing is not enough) Very difficult - usually gcc uses ~25M per process (small source files), but I've seen >100M (most larger C++ files) and heard of ~600M per process for MySQL Limiting that is beyond the scope of portage. wkr, Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
[gentoo-dev] pending dooooooom of use.defaults
as one of the new sane features of the next portage-2.1_pre release, we're looking to cut out use.defaults support existing stable users wont be affected as the 2.0.x versions will continue to carry support for this, but some of you stable users may notice some USE flags suddenly "disappearing" to recap, use.defaults inserts USE flags for you based upon what packages you have installed when you havent declared a preference. for example, if you have neither '-cups' or 'cups' in your USE (either in your make.conf, profile, env, whatever), but you do have the net-print/cups package installed, portage will add 'cups' to your USE -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Parallizing ebuilds - 'trivial' ebuilds
Patrick Lauer posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 13 Jan 2006 12:06:28 +0100: > Very difficult - usually gcc uses ~25M per process (small source files), > but I've seen >100M (most larger C++ files) and heard of ~600M per > process for MySQL > > Limiting that is beyond the scope of portage. There's one point in the kmail/kdepim (split/monolithic) build where with USE=kdeenablefinal on AMD64, a single process takes > 700 meg, based on my results. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 07:49, Brian Harring wrote: > On Wed, Jan 04, 2006 at 10:05:52PM -0800, Corey Shields wrote: > > Where is the centralized vision that everyone is working together > > here that people not directly related to each project will buy in to > > and therefore do what they can to see it succeed? > > We've had centralized visions for a long while. Recall use/slot deps? > > See them available anywhere? Those requirements have been there since before 1.0. When the team was still smaller. > > Vision ofr an installer? Yes, underway now, but the centralized vision > really didn't do jack for actually acquring folk to work on it, did > it (feel free to chime in agaffney since it's effectively yours now a > days). Actually we put a lot of effort into starting it off, along with other prospective improvement projects. This stuff however stands and falls with people being willing to do the work. While I have been instrumental in starting it up, I never had time to do the work myself. > > Portage team is running in one direction, > > webapps another, GLI a third direction (while kicking anyone who > > wishes to run with them in the nuts). > > Examples would be lovely. > Look at gentoo-dev@gentoo.org archives for the last years. I'm not saying that this is wrong, or unnatural. It is something that could be expected. A group of 300 people is not similar to a team of 40. The big amount of developers creates subgroups. That includes communication problems. > > Gentoo won't fail.. I don't believe that is what Kurt or Lance are > > saying. I think the point was that Gentoo is not moving at the > > typical pace of OSS development, and we believe that it is the > > organizational structure that is holding it back. > > Actually, here's where I'm going to get lynched- (both for bringing up > anon* after pissing y'all off by asking about it less then 24 hours > previously, and stepping on other toes). Organizational structure doesn't mean bureaucracy. We already saw that didn't work. Open source organizations are different from normal ones though. This includes chronic lack of time for many participants. > Typical foss project is optimized for one thing, and one thing alone- > maximal usage of available resources. It has to be *easy* for folks > to contribute whatever time they have- this means eliminating as much > menial/manual work as possible. Gentoo is not a typical OSS project either. Developing a distribution is fundamentally different from developing one application. > Further, foss has something of a rapid release cycle. We're actively > trying to move in the opposite direction if you consider the actual > implication of trying to widen the unstable keywording gap- I'm not > stating QA is bad, what I'm stating is that QA explicitly requires > delays built in (whether via multiple reviews by devs, or letting the > changes sit for a while). We try to make a better gentoo. This does not mean do what every other foss project does. No matter how applicable. > Why has gentoo gotten slower as it's gotten larger? Because the lone > wolf developer has less bullshit to deal with, they can just hammer > towards their goal. Introduce more folk into it, waste more of their > time syncing up with each other, more time of those who see their > goal, know how to get their, having to run it past everyone who wants > to be know what's afoot. Also remember the lack of stability at that time. And the fact there were less packages. And the fact that we had Daniel, who often just said "Yes" or "No", shortcutting any decision. > > 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. > > Not trying to stick it to you, but I think what you're pointing at as > good is fundamentally the issue here- more process tagged into gentoo > isn't going to help anything, just push us further towards > debianization (something that's bugged me for the last 18 months I > might add). What I think people are arguing about is how to prevent this. > > What I've seen with gentoo is bluntly, wasted resources (bit > intentional in some cases). We've been progressing more towards > keeping everyone in the loop rather then letting folks spring on ahead > and get things done (sometimes with a bit of a mess in the process). > > Note I said 'intentional'; seems like people have been pushing for > gentoo as a whole to slow down (note the enterprise > concerns/complaints that hit the ml every 6 months for example). There you've got it wrong in my opinion. Enterprise does not mean slow the project down. It means create subproject that at some point takes a snapshot of the distribution and makes a stable fork from that that only changes for security issues. It should not limit the progress of the project itself. > Dunno. Maybe it's al
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Friday 06 January 2006 00:17, Carsten Lohrke wrote: > > To make it short: When you really have something important to say, post > it to the appropriate mailing list - and post the whole text, not a > ridiculous link to your blog, most people are not interested in and > won't read! The same goes for our userbase: They're right to expect a > single source of general information and one for security information, > but not being forced to follow lots of blogs. Even better, send a mail to Ulrich, or to the gwn-feedback address, and propose a nice article in the GWN, and possibly on the homepage. That's why we have them. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpjaV0wJU2zn.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 17:20, Patrick Lauer wrote: > > But it's already getting too bureaucratic ;-) > It's getting more and more difficult to get things done, more and more > people / groups / herds to wait on to decide "obvious" things. > They shouldn't. If there is anything I learned is that a mailing list never comes to a "decision". At some point the principal stakeholder (the person waiting for the decision) must make a conclusion, and get to work. It works. The support was there, people will follow, end else there is repoman to force them to ;-). > For example - our baselayout supports UML and vServer (almost fully) > native. Most of you won't see that, but to those that do it's something > that's really nice. One of the reasons that gentoo is still my favourite distro. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5goZauTR0f.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 18:03, Patrick Lauer wrote: > Exactly :-) But I guess many among us have become a bit disillusioned > and try to stay away from what is perceived as useless trolling and > silly infights. So things either stall in discussion or get implemented > with the "obvious" flawed approach (early webapp-config and portage are > good examples) and then take a long time to become "fixed". There's > still a lot of good stuff happening, but as someone else said in this > thread, "we suck at execution" :-( I guess, the council should be more brave, and make decisions like rejecting flawed approaches. Even when discussions have not been thrown up and re-eaten again. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpcPZHhp4dPQ.pgp Description: PGP signature
Re: [gentoo-dev] Monthly Gentoo Council Reminder for January
On Thursday 05 January 2006 21:09, Aron Griffis wrote: > I think there is a Post Hoc fallacy happening here: A happened before > B, therefore A must be causing B. In the case at hand: A = loss of > leader, B = lack of progress. While A might be the cause of B, it is > dangerous to jump to that conclusion without more than the sequence as > support. From what I remember from talking with Daniel, the oposite is more through. Daniel felt that things were getting nowhere, he was overloaded and brickwalled at the same time, and to make worse had financial problems. So indeed rather a fallacy. > First, Gentoo's developers are not going to follow a leader's > direction unless they sincerely agree with it. Since we're all > volunteers, the only cooperative work we're going to see is when > people agree with a goal. Therefore it doesn't matter whether you > name somebody "our leader" or if they're just another developer, > either way they're going to have to convince people to play along. > Our current model already allows for centralized leadership via > meritocracy: any developer can step up to the plate and be king for > the day, they just have to have a good idea and convince others to go > along with it. People should also notice the difference between leader and boss. > Second, I think the factualness of B is in question. A few people > have brought up examples of progress being made within Gentoo. The > problem here appears to be that the progress being made is not in the > same areas where some people are looking. Which brings up the > question: How is Gentoo falling short in your eyes? Are you certain > that those specific areas are related to the non-existence of a boss? Part of it is portage, and that is getting somewhere now. The "boss" stepped down, so that others than him can work on it too. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpLXgTkT5jgQ.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
On Tue, 10 Jan 2006 15:12:27 -0600 Lance Albertson <[EMAIL PROTECTED]> wrote: | Last I knew, its not a simple task for generating those nice looking | html pages that ciaranm made a while back for the developer docs. | When I asked him about (he can probably provide more detail), It took | a lot of processing time and wasn't that scalable. Now, I'm not sure | if anything has changed since then. If you're using docutils, then yes, it's reaallly slow. I've got a (very fast) parser that handles a decent subset of the RST spec written, but getting it converted to be usable in a general kind of way isn't too high up my list of priorities... The thing is... If you're trying to do RST -> GuideXML, you'll run into all kinds of weirdness because of the GuideXML heading structure. You'll also run into a load more weirdness because about half of the GLEPs currently massively abuse blockquotes (in all but one case accidentally). See, this is a list in RST: * one * two And this is a list inside a blockquote: * one * two Very easy to screw up, especially since docutils goes to great lengths to create output even if the input is highly weird. My own parser moans on anything like that -- it disallows most nested structure markup -- which means it's useless on most GLEPs unless someone goes through and does some serious whitespace cleanups... -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
Patrick Lauer wrote: > On Fri, 2006-01-13 at 19:53 +0900, Kalin KOZHUHAROV wrote: > >>>Make this distributed tool for tar zip bzip2 and gzip and I'm in, I >>>don't think it would be useful with anything else than Gigabit Ethernet. > > One 2Ghz CPU can't even saturate a 100Mbit line with bzip2 as far as I > can tell. > Although the speedups won't be extreme it could just work. > > >>>We might want to have in the make.conf 2 separate variables, one of them >>>saying how many threads can be run on the machine, then How many >>>threads/process across a cluster. >>> >>>For example, my Dual Xeon EM64T file server can do make -j4 locally, >>>like in make install, make docs etc etc, But for compiling I can use >>>-j20, really not useful over -j8 anyway. But the point is, it would be >>>usefully to separate the load distribution on the local machine and >>>cluster nodes. >> >>As the discusison started... >> >>I would like to be able to limit the -jN when there is no distcc host >>available or when compiling c++ code, otherwise my poor laptop is dead with >>-j5 compiling pwlib when the network is down > > As far as I can tell distcc isn't smart enough for dynamic load balancing. > One could hack portage to "test" each server in the distcc host list and > remove missing servers for each run - doesn't look elegant to me. Yes, might be a solution, even if not elegant. I am thinking also of automating distcc configuration (i.e. no need to run --set-hosts) and one idea is to use DNS with some TXT record, but that is just an idea - no patching is done yet. Not sure if distcc has local limiter, i.e. if it it set with "localhost/2" and portage user (or some other user != root) tries to start 3 processes, the 3rd just blocks (and not take memory). I think not, so this thing might be interesting to implement (for "old" laptops with less memory). I think I should resubscribe to the distcc list :-) >>It is particular example, but being able to limit portage in some way as >>total CPU, total MEM might be interesting (just nice-ing is not enough) > > Very difficult - usually gcc uses ~25M per process (small source files), but > I've seen >100M (most larger C++ files) and heard of ~600M per process for > MySQL > > Limiting that is beyond the scope of portage. Hmm, may be not limiting the total usage, but more like just adjusting MAKEOPTS='-j1' in some cases (NOTE: to /me, define "some cases"). Implementing the above "Local limiter" in distcc will solve that automagically. Kalin. -- |[ ~~ ]| +-> http://ThinRope.net/ <-+ |[ __ ]| -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
Mike Frysinger wrote:
> as one of the new sane features of the next portage-2.1_pre release, we're
> looking to cut out use.defaults support
>
> existing stable users wont be affected as the 2.0.x versions will continue to
> carry support for this, but some of you stable users may notice some USE
> flags suddenly "disappearing"
>
> to recap, use.defaults inserts USE flags for you based upon what packages you
> have installed when you havent declared a preference. for example, if you
> have neither '-cups' or 'cups' in your USE (either in your make.conf,
> profile, env, whatever), but you do have the net-print/cups package
> installed, portage will add 'cups' to your USE
Can I just ask, since when is this "feature" on? I have never run into it...
Or is it because I always had:
USE="-* ${MY_USE}"
in /etc/make.conf?
Is "-*" counted as preference? I thought that is ignoring just the ones in
the profile ("just" is plain wrong, as I didn't even feel there were other
useflags :-)
Kalin
--
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: > as one of the new sane features of the next portage-2.1_pre release, we're > looking to cut out use.defaults support > > existing stable users wont be affected as the 2.0.x versions will continue to > carry support for this, but some of you stable users may notice some USE ^^ > flags suddenly "disappearing" I'm a bit confused, existing stable users won't be affected, but they will notice use flags "disappearing"? Wouldn't that mean they are affected or did you simply mistype and mean unstable? > to recap, use.defaults inserts USE flags for you based upon what packages you > have installed when you havent declared a preference. for example, if you > have neither '-cups' or 'cups' in your USE (either in your make.conf, > profile, env, whatever), but you do have the net-print/cups package > installed, portage will add 'cups' to your USE That's the current behaviour in stable 2.0.x and will be gone with 2.1, right? I'm a little confused now, could you clarify this? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpEq7ORbfSdJ.pgp Description: PGP signature
Re: [gentoo-dev] pending dooooooom of use.defaults
On Friday 13 January 2006 11:15, Kalin KOZHUHAROV wrote:
> Or is it because I always had:
> USE="-* ${MY_USE}"
> in /etc/make.conf?
yes
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Friday 13 January 2006 11:15, Wernfried Haas wrote: > On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: > > existing stable users wont be affected as the 2.0.x versions will > > continue to carry support for this, but some of you stable users may > > notice some USE > > flags suddenly "disappearing" > > I'm a bit confused, existing stable users won't be affected, but they > will notice use flags "disappearing"? Wouldn't that mean they are > affected or did you simply mistype and mean unstable? correct, should have said unstable > > to recap, use.defaults inserts USE flags for you based upon what packages > > you have installed when you havent declared a preference. for example, > > if you have neither '-cups' or 'cups' in your USE (either in your > > make.conf, profile, env, whatever), but you do have the net-print/cups > > package installed, portage will add 'cups' to your USE > > That's the current behaviour in stable 2.0.x and will be gone with > 2.1, right? yes -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] baselayout-1.11.14 stabilization
Mike Frysinger wrote: > ignoring the two releng issues (since that's a bug with both 1.11.13 and > 1.11.14), any last thoughts before i do this ? i'll wait until sunday > nite ;) > -mike Looks good here (PPC64)! markus pgpqsx5c5iXVS.pgp Description: PGP signature
Re: [gentoo-dev] Projects and simple guides
Ciaran McCreesh wrote: [Fri Jan 13 2006, 08:48:21AM CST] > Very easy to screw up, especially since docutils goes to great lengths > to create output even if the input is highly weird. My own parser moans > on anything like that -- it disallows most nested structure markup -- > which means it's useless on most GLEPs unless someone goes through and > does some serious whitespace cleanups... I'm actually willing to do that, albeit not until after my brief vacation. -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgp7JnWOHDreI.pgp Description: PGP signature
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
>>> I would like to be able to limit the -jN when there is no distcc host >>> available or when compiling c++ code, otherwise my poor laptop is dead with >>> -j5 compiling pwlib when the network is down >> As far as I can tell distcc isn't smart enough for dynamic load balancing. >> One could hack portage to "test" each server in the distcc host list and >> remove missing servers for each run - doesn't look elegant to me. > dn > Yes, might be a solution, even if not elegant. I am thinking also of > automating distcc configuration (i.e. no need to run --set-hosts) and one > idea is to use DNS with some TXT record, but that is just an idea - no > patching is done yet. you may be interested in the SRV DNS record, take a look at http://www.dns-sd.org/ServiceTypes.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: > as one of the new sane features of the next portage-2.1_pre release, we're > looking to cut out use.defaults support Could you add a USE_ORDER without "auto" to /etc/make.globals for that release, please, or alternatively provide some other way of checking whether use.defaults is read? This would greatly help me out with ufed, which currently has no way to check this, and instead has to hardcode "env:pkg:conf:auto:defaults" as the default USE_ORDER just like portage does. pgpx4vERZRK22.pgp Description: PGP signature
Re: [gentoo-dev] pending dooooooom of use.defaults
Can we get this on the website/announce? I agree that auto-use is the
suck and that it needs to die a long excrutiating death, but I think a
lot of users will be like wtf when 2.1 hits stable and --newuse turns up
a massive crapload of packages.
Whether this announced now, or when portage-2.1 hits stable, or both, I
don't really care. If you need a ditty to post about it we can probably
whip one up.
Mike Frysinger wrote:
On Friday 13 January 2006 11:15, Kalin KOZHUHAROV wrote:
Or is it because I always had:
USE="-* ${MY_USE}"
in /etc/make.conf?
yes
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 2006-01-13 at 13:26 -0500, Alec Joseph Warner wrote: > but I think a > lot of users will be like wtf when 2.1 hits stable and --newuse turns > up > a massive crapload of packages. Could we include a simple script to add these USE to the users make.conf before they upgrade to 2.1. Without somthing like this, I see a wave of 'bugs' about it. -- Lares Moreau <[EMAIL PROTECTED]> | LRU: 400755 http://counter.li.org lares/irc.freenode.net | Gentoo x86 Arch Tester | ::0 Alberta, Canada Public Key: 0D46BB6E @ subkeys.pgp.net | Encrypted Mail Preferred Key fingerprint = 0CA3 E40D F897 7709 3628 C5D4 7D94 483E 0D46 BB6E signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] pending dooooooom of use.defaults
On Friday 13 January 2006 12:49, Harald van Dijk wrote: > On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: > > as one of the new sane features of the next portage-2.1_pre release, > > we're looking to cut out use.defaults support > > Could you add a USE_ORDER without "auto" to /etc/make.globals for that > release, please, or alternatively provide some other way of checking > whether use.defaults is read? you should be able to get the value from `portageq envvar USE_ORDER` i know this doesnt currently work, but imo that's a bug that should be fixed -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Parallizing ebuilds - 'trivial' ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kalin KOZHUHAROV wrote: > Patrick Lauer wrote: >> On Fri, 2006-01-13 at 19:53 +0900, Kalin KOZHUHAROV wrote: >> Make this distributed tool for tar zip bzip2 and gzip and I'm in, I don't think it would be useful with anything else than Gigabit Ethernet. >> One 2Ghz CPU can't even saturate a 100Mbit line with bzip2 as far as I >> can tell. >> Although the speedups won't be extreme it could just work. >> >> We might want to have in the make.conf 2 separate variables, one of them saying how many threads can be run on the machine, then How many threads/process across a cluster. For example, my Dual Xeon EM64T file server can do make -j4 locally, like in make install, make docs etc etc, But for compiling I can use -j20, really not useful over -j8 anyway. But the point is, it would be usefully to separate the load distribution on the local machine and cluster nodes. >>> As the discusison started... >>> >>> I would like to be able to limit the -jN when there is no distcc host >>> available or when compiling c++ code, otherwise my poor laptop is dead with >>> -j5 compiling pwlib when the network is down >> As far as I can tell distcc isn't smart enough for dynamic load balancing. >> One could hack portage to "test" each server in the distcc host list and >> remove missing servers for each run - doesn't look elegant to me. > > Yes, might be a solution, even if not elegant. I am thinking also of > automating distcc configuration (i.e. no need to run --set-hosts) and one > idea is to use DNS with some TXT record, but that is just an idea - no > patching is done yet. Recipe for disaster, specially in a place like mine where sparc, alpha, x86_64 and ppc32/64 mix... not counting ia64 for a test run soon... If you really want to do this, someone has to make a rendezvous a la Apple. Where not only distcc says I am available but I am also doing the right stuff. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDx/nsP0/FkJ0eBc0RAn8aAJ9h8C1QFO0HyQmBINl2erPljgaEYwCfcOBF yPpDJ/KElWfotWqNvWYPq3s= =XM29 -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 2006-01-13 at 06:57 -0500, Mike Frysinger wrote: > as one of the new sane features of the next portage-2.1_pre release, we're > looking to cut out use.defaults support I see this as a good and bad thing. Good in one hand that less autojunk would be enabled like python/perl bindings not being added to every program on your system that supports it. Bad in the other hand I see the state of profiles getting worse=more bloated. The autouse itself is not a bad feature or idea if it were used properly. Problem is that it's not been used properly. If it were limited to simple things like just X and the things that actually make sense then it would even be fine to keep and would allow some of the more bloated (default-linux) profiles to be cleaned up. Shrug. I like the existing behavior and the power of deciding for myself when and where I want to take advantage of USE_ORDER= > existing stable users wont be affected as the 2.0.x versions will continue to > carry support for this, but some of you stable users may notice some USE > flags suddenly "disappearing" > > to recap, use.defaults inserts USE flags for you based upon what packages you > have installed when you havent declared a preference. for example, if you > have neither '-cups' or 'cups' in your USE (either in your make.conf, > profile, env, whatever), but you do have the net-print/cups package > installed, portage will add 'cups' to your USE > -mike -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 13 Jan 2006 15:13:02 -0500 solar <[EMAIL PROTECTED]> wrote: | The autouse itself is not a bad feature or idea if it were used properly. | Problem is that it's not been used properly. No, it's bad. It's another thing that makes correct dependency resolution impossible. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 2006-01-13 at 20:23 +, Ciaran McCreesh wrote: > On Fri, 13 Jan 2006 15:13:02 -0500 solar <[EMAIL PROTECTED]> wrote: > | The autouse itself is not a bad feature or idea if it were used properly. > | Problem is that it's not been used properly. > > No, it's bad. It's another thing that makes correct dependency > resolution impossible. If your going to contradict somebody why don't you give more detail and less opinion. -- solar <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Fri, 13 Jan 2006 15:50:08 -0500 solar <[EMAIL PROTECTED]> wrote: | On Fri, 2006-01-13 at 20:23 +, Ciaran McCreesh wrote: | > On Fri, 13 Jan 2006 15:13:02 -0500 solar <[EMAIL PROTECTED]> wrote: | > | The autouse itself is not a bad feature or idea if it were used | > | properly. Problem is that it's not been used properly. | > | > No, it's bad. It's another thing that makes correct dependency | > resolution impossible. | | If your going to contradict somebody why don't you give more detail | and less opinion. *shrug* It's pretty obvious. You probably already know this, but for the benefit of those who really haven't thought about it rather than those who just want to go around trolling... When a package that toggles a USE flag gets installed, the dep resolver has to go back and regenerate the deplist with that USE flag changed. However, this can cause the package that would have enabled the USE flag to no longer be installed. -- Ciaran McCreesh : Gentoo Developer (King of all Londinium) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] pending dooooooom of use.defaults
IMHO a lot of the auto-use stuff that is "mis-used" is moreso what IUSE defaults is for. I have a crappy patch for IUSE defaults that I may try to work on so that it can be merged in the 2.1/2.2 branch. I realize that this is probably a bit far off, but will hopefully improve the situation. Of course at that point we can dump the crappy nocxx flags too ;) solar wrote: On Fri, 2006-01-13 at 06:57 -0500, Mike Frysinger wrote: as one of the new sane features of the next portage-2.1_pre release, we're looking to cut out use.defaults support I see this as a good and bad thing. Good in one hand that less autojunk would be enabled like python/perl bindings not being added to every program on your system that supports it. Bad in the other hand I see the state of profiles getting worse=more bloated. The autouse itself is not a bad feature or idea if it were used properly. Problem is that it's not been used properly. If it were limited to simple things like just X and the things that actually make sense then it would even be fine to keep and would allow some of the more bloated (default-linux) profiles to be cleaned up. Shrug. I like the existing behavior and the power of deciding for myself when and where I want to take advantage of USE_ORDER= existing stable users wont be affected as the 2.0.x versions will continue to carry support for this, but some of you stable users may notice some USE flags suddenly "disappearing" to recap, use.defaults inserts USE flags for you based upon what packages you have installed when you havent declared a preference. for example, if you have neither '-cups' or 'cups' in your USE (either in your make.conf, profile, env, whatever), but you do have the net-print/cups package installed, portage will add 'cups' to your USE -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] pending dooooooom of use.defaults
On Friday 13 January 2006 15:13, solar wrote: > On Fri, 2006-01-13 at 06:57 -0500, Mike Frysinger wrote: > > as one of the new sane features of the next portage-2.1_pre release, > > we're looking to cut out use.defaults support > > I see this as a good and bad thing. Good in one hand that less autojunk > would be enabled like python/perl bindings not being added to every > program on your system that supports it. Bad in the other hand I see > the state of profiles getting worse=more bloated. i dont really see the profiles getting any more USE flags than they already have ... as for bloated, i see it as being a more-than-worth-it trade off when it comes to stability a profile-based USE will always stay the same while a autouse-based USE may fluctuate greatly based upon what the user emerges from day to day > The autouse itself is not a bad feature or idea if it were used properly. there is no used properly or improperly when it comes to use.defaults -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] learn to use RESTRICT=test people
from time to time i see this crap:
src_test() { :; }
dont do this
use RESTRICT=test
-mike
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] learn to use RESTRICT=test people
On Fri, Jan 13, 2006 at 06:03:16PM -0500, Mike Frysinger wrote:
> from time to time i see this crap:
> src_test() { :; }
>
> dont do this
>
> use RESTRICT=test
Can we have a RESTRICT=compile too, please? ;)
./Brix
--
Henrik Brix Andersen <[EMAIL PROTECTED]>
Gentoo Metadistribution | Mobile computing herd
pgp46xwgo03Gs.pgp
Description: PGP signature
[gentoo-dev] Re: pending dooooooom of use.defaults
Harald van Dijk posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 13 Jan 2006 18:49:42 +0100: > On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: >> as one of the new sane features of the next portage-2.1_pre release, we're >> looking to cut out use.defaults support > > Could you add a USE_ORDER without "auto" to /etc/make.globals for that > release, please, or alternatively provide some other way of checking > whether use.defaults is read? This would greatly help me out with ufed, > which currently has no way to check this, and instead has to hardcode > "env:pkg:conf:auto:defaults" as the default USE_ORDER just like portage > does. According to previous posts, USE_ORDER will be going away with use.defaults, because that was really the only reason it was there in the first place as there's no other sane ordering possible, if it is removed. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] learn to use RESTRICT=test people
Henrik Brix Andersen wrote: Can we have a RESTRICT=compile too, please? ;) Right after RESTRICT=lamejokes is implemented :P -- Simon Stelling Gentoo/AMD64 Operational Co-Lead [EMAIL PROTECTED] -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: pending dooooooom of use.defaults
On Fri, Jan 13, 2006 at 04:39:38PM -0700, Duncan wrote: > Harald van Dijk posted <[EMAIL PROTECTED]>, excerpted > below, on Fri, 13 Jan 2006 18:49:42 +0100: > > > On Fri, Jan 13, 2006 at 06:57:24AM -0500, Mike Frysinger wrote: > >> as one of the new sane features of the next portage-2.1_pre release, we're > >> looking to cut out use.defaults support > > > > Could you add a USE_ORDER without "auto" to /etc/make.globals for that > > release, please, or alternatively provide some other way of checking > > whether use.defaults is read? This would greatly help me out with ufed, > > which currently has no way to check this, and instead has to hardcode > > "env:pkg:conf:auto:defaults" as the default USE_ORDER just like portage > > does. > > According to previous posts, USE_ORDER will be going away with > use.defaults, because that was really the only reason it was there in the > first place as there's no other sane ordering possible, if it is removed. There are other sane orderings possible, one being pkg:env:conf:defaults so that USE=xxx emerge -NpDuv world will show exactly what adding xxx to make.conf will do. I don't recall where I saw this, unfortunately, but I do know that some people actually use it for this. (Okay, maybe that's really the only other sane ordering.) pgpMg6wyFCtLZ.pgp Description: PGP signature
Re: [gentoo-dev] Re: pending dooooooom of use.defaults
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 >>According to previous posts, USE_ORDER will be going away with >>use.defaults, because that was really the only reason it was there in the >>first place as there's no other sane ordering possible, if it is removed. > > > There are other sane orderings possible, one being pkg:env:conf:defaults > so that USE=xxx emerge -NpDuv world will show exactly what adding xxx to > make.conf will do. I don't recall where I saw this, unfortunately, but I > do know that some people actually use it for this. (Okay, maybe that's > really the only other sane ordering.) I would prefer to keep USE_ORDER for now, since I was going to replace the "auto" dict with the "default-iuse" which means you can choose not to stack these new flags. Although it may be a hack, we have no better way of managing use flag stacks at the moment. - -Alec Warner -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ8h0XGzglR5RwbyYAQJ5rRAAie3nIGMJQQQuy/tI9as+jniZ2BJ5fDSj Z0sMS/qdPUItdfMQ6WLAthG7Y7RBA3u8rKuYMEDGUZ4ile7s43s7YPpCUXuwwmF8 a4uiX2TY16yE+1I9W7Agp1Bl3fmtL79vYg+39BQooFq2kmcWMFmTO+dE/jbO2bxI 2ttPVERaKHJn+Nu44otqQ84hQ2bQ2tJtLBlmUvCwz5RBVhN9Jj8G/3ZOc/hMuUDo W/ytxHr4AJ/fpMa4ksRBI4jz2KjDbBurYH5tyI3ZRNqVGxzB4Oj4CzakRHevHGs1 h7NeJM2ZGI2r6K5iZlzPMUO2UWaO17KUo1C2w1Oa7Xyl5Zhd8UDphsf/xXCsr13d Goyg/zwCJUIp3cSvp3ajQgxVCDQtHVcT4TKz/6ph7A/UTRn67Byl80cm8rHc7Xl+ Bi6X7UHPURzYEqxqshbfL0eEoOjqxqgQTl9i9lAmiKBIjlgPxH8DuxNOJx1JmcTV tFAa3ktDRWJMjuSPN+9dn4P+9msdlhB1OVQtM9sEvb4Wu2TQzzPWijn42bsWLwxB EBESmuXyycrwuaJD2YC+bdHsFEsdNssKeM1rU7w332fMefQu4ttXYaoAh2HtR9Pf 5lzB2aOp5iL9CCXL+SIQzsRcoIkSva+4xUGMgsRW4ulpVsy5sy9gOO5CHY0s4YjQ jEiI5ljabUo= =dbSA -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: pending dooooooom of use.defaults
Alec Warner posted <[EMAIL PROTECTED]>, excerpted below, on Fri, 13 Jan 2006 22:47:40 -0500: > >>>According to previous posts, USE_ORDER will be going away with >>>use.defaults, because that was really the only reason it was there in the >>>first place as there's no other sane ordering possible, if it is removed. >> >> >> There are other sane orderings possible, one being pkg:env:conf:defaults >> so that USE=xxx emerge -NpDuv world will show exactly what adding xxx to >> make.conf will do. I don't recall where I saw this, unfortunately, but I >> do know that some people actually use it for this. (Okay, maybe that's >> really the only other sane ordering.) > > I would prefer to keep USE_ORDER for now, since I was going to replace > the "auto" dict with the "default-iuse" which means you can choose not > to stack these new flags. Although it may be a hack, we have no better > way of managing use flag stacks at the moment. I was wondering... but nobody challenged it at the time the plan was mentioned (the previous posts I referred to), and that's one thing I haven't messed with (yet?), so /I/ was keeping quiet. Maybe I misunderstood the entire thing, but I don't think so because I remember being rather unconfortable with it just being outright dismissed like that. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
