From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JKIHv-0007NY-KS for garchives@archives.gentoo.org; Wed, 30 Jan 2008 19:08:00 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 0EBDDE04BF; Wed, 30 Jan 2008 19:06:49 +0000 (UTC) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by pigeon.gentoo.org (Postfix) with ESMTP id 8DB70E04BF for ; Wed, 30 Jan 2008 19:06:48 +0000 (UTC) Received: by fk-out-0910.google.com with SMTP id 18so632163fkq.2 for ; Wed, 30 Jan 2008 11:06:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=lYvgxBQoFtYpLUov1tUENcbI4ZC96JW2lf58MhblfpE=; b=VCr3iwGVP9eiaBJZRvI452khje30QDJROnVDQltmNK2tFe02f74Qz5W+no8gxTg30BFI283RZfbQgNVt2v1yQOldcvthKPBSyC0RtzXs87ap94QFcq6xI8NhhqVf3jpBSr40CaHZhBQekV8fMiq9zoJvVGpNGa5husLD0Q8RUuE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uIaqKH3W4TRK31/2WJ6bmW0EHm1Z8UAfkr6MAsVqiWEeGeluMKgiRZzNsnsbCurHT2GR3oNvEBemXmN6wB5JLUb9ZUzUQ+ACgJBWTZ99l6Yn1ZhTPlsHSCT5QSjf+NKasGRzMWD+56IHbv9LKOkkL1q2vR59ebWz6txlBlatBsE= Received: by 10.82.158.12 with SMTP id g12mr2004748bue.18.1201720007155; Wed, 30 Jan 2008 11:06:47 -0800 (PST) Received: by 10.82.141.7 with HTTP; Wed, 30 Jan 2008 11:06:47 -0800 (PST) Message-ID: Date: Wed, 30 Jan 2008 19:06:47 +0000 From: Beso To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: madwifi-ng not compile in amd64 In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_21909_9295397.1201720007148" References: <1201555535.24379.1.camel@gentoo> <1201645850.7098.8.camel@gentoo> <200801300220.21430.volker.armin.hemmann@tu-clausthal.de> X-Archives-Salt: 911a247f-1ef2-4b59-9b63-92218f122404 X-Archives-Hash: 99cf62ec66c76077482cb41dcfe85faf ------=_Part_21909_9295397.1201720007148 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/1/30, Duncan <1i5t5.duncan@cox.net>: > > Beso posted > d257c3560801300032m6f6c51adwc9f4bd75da066609@mail.gmail.com, excerpted > below, on Wed, 30 Jan 2008 09:32:57 +0100: > > > i'd also advise to use the the --buildpkg feature for some high > > compiling time packages like kdebase, gcc, openoffice or mplayer. since > > these packages are likely to be the same for quite some time and they > > might be pushed into recompilation by some other updates having them > > packaged on disk (they'd require disk space when packaged) would mean to > > skip all the compilation part and jump directly to the install one (of > > course if they would need to be recompiled portage would do it). > > IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4 gigs > of room for the packages) is one of the most under-advertised power-user > tools Gentoo has. The binaries are just so handy to have around, giving > one all the advantages of a binary distribution if you need to remerge or > need to fetch a "pristine" config file for some reason, without losing > all the benefits and extra control allowed by from-source, since you > compile everything initially anyway. i only use it on system packages like gcc that are mandatory for compiling something (just in case something breaks) and on some big packages that don't update frequently (kdebase, kdelibs). this requires less space than buildpkg for all world packages. of course having this option enabled needs frequent distcleans after updates since there's the risk of having there different versions of the same package that aren't used. Of course, if something big dependency-wise changes, one often ends up > rebuilding from-source anyway, so the linking gets updated to the new > dependencies, so buildpkg is not a cure-all, but it certainly has its > uses, and I'd be hard pressed to try to do without it! it sure helps when a rebuild is triggered after a lib soname update or relinking issues. in that case there's no need to recompile but only to relink and having binary builds helps a lot. > i still think that having the base system on the unstable arch isn't a > > very good idea. i've used the same stuff for quite some time, but i > > found out that it isn't a very good stuff. or at least 6 months ago > > wasn't a good idea. > > I've never had serious issues in that regard. I'd suggest it's because > I /always/ use --update --deep --newuse on my emerge world updates, so > stuff tends to be pretty up to date anyway, and due to regular use of > revdep-rebuild and emerge --depclean to keep the system hygiene level > high. the problem is always there: major or blocking bugs getting into the unstable branch after the update of the package (has happened with dhcpcd for example) that makes gentoo devs mask the package the next day or so. so for people like me that update daily this could be troublesome if it happens on the system packages. The cure, of course, is a faster machine! =8^) Gentoo was reasonable > with my old dual Opteron 242, but merges for things such as gcc, glibc, > and DEFINITELY whole desktop updates like KDE, tended to be a chore. The > upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory (tho > 4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE > difference. Where KDE 3.5 updates, for example, would take ~12 hours > back when I had a gig of memory and no tmpfs, and ~8 hours after > upgrading the memory, I was running the KDE4-svn ebuilds from the > overlay, and could compile all of KDE4 (well, most, I didn't have kdeedu > or kdedevel merged) in ~4 hours with the dual dual-cores and > PORTAGE_TMPDIR on tmpfs with 8 gigs memory, generally < 2 hours with > everything ccached if I did it daily, and often closer to a single hour! this is a high end machine. opteron is better than a normal athlon x2 in terms of compilation and having 8gb on a server mobo, that differs from normal mobos, is not affordable for every user. my system is about the average one (2ghz processor, 1gb ram, 80gb hdd) for notebooks and quite average one for desktops. remember that nuveau devs still work on athlons or pentium 3 hw, and that hw is not dead yet. your system nowadays is a middle-high end one. Really. Those who've not yet had a chance to try quad cores (however you > get them) and a good 4 gigs memory minimum, it really /does/ make running > Gentoo pretty trivial. A couple years from now when that's a lower end > new system, it's likely Gentoo and other from-source distributions will > see a fresh rise in popularity, because the time differences between > grabbing a binary update and grabbing a from-source update begin to be > pretty trivial, while all the advantages of from source, in particular, > greater control of dependencies without bloat, remain. At that level, > the admin time, just figuring out what you are going to install, and > dealing with the config updates, etc, is as much a factor as the compile > time. By the time we reach 8 cores and a full 8 to 16 gig RAM, that > admin time will be the MAJOR factor, with the actual compile time almost > entirely a non-factor, so the advantages of running binary pretty much > disappear while the advantages of running from-source remain as big as > they ever were! well, this is true for minor packages, but kdelibs or kdebase for example are still quite big and if you're not a developer you won't go around compiling it everyday or so. -- > Duncan - List replies preferred. No HTML msgs. > "Every nonfree program has a lord, a master -- > and if you use the program, he is your master." Richard Stallman > > -- > gentoo-amd64@lists.gentoo.org mailing list > > -- dott. ing. beso ------=_Part_21909_9295397.1201720007148 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

2008/1/30, Duncan <1i5t5.duncan@cox.net>:
Beso <givemesugarr@gmail.com> posted
d257c3560801300032m6f6c51adwc9f4bd75da066609@mail.gmail.com, excerpted
below, on  Wed, 30 Jan 2008 09:32:57 +0100:

> i'd also advise to use the the --buildpkg feature for some high
> compiling time packages like kdebase, gcc, openoffice or mplayer. since
> these packages are likely to be the same for quite some time and they
> might be pushed into recompilation by some other updates having them
> packaged on disk (they'd require disk space when packaged) would mean to
> skip all the compilation part and jump directly to the install one (of
> course if they would need to be recompiled portage would do it).

IMO --buildpkg (or better yet, FEATURES=buildpkg, if you've got 2-4 gigs
of room for the packages) is one of the most under-advertised power-user
tools Gentoo has.  The binaries are just so handy to have around, giving
one all the advantages of a binary distribution if you need to remerge or
need to fetch a "pristine" config file for some reason, without losing
all the benefits and extra control allowed by from-source, since you
compile everything initially anyway.

i only use it on system packages like gcc that are mandatory for compiling something (just in case something breaks) and on some big packages that don't update frequently (kdebase, kdelibs). this requires less space than buildpkg for all world packages. of course having this option enabled needs frequent distcleans after updates since there's the risk of having there different versions of the same package that aren't used.

Of course, if something big dependency-wise changes, one often ends up
rebuilding from-source anyway, so the linking gets updated to the new
dependencies, so buildpkg is not a cure-all, but it certainly has its
uses, and I'd be hard pressed to try to do without it!

it sure helps when a rebuild is triggered after a lib soname update or relinking issues. in that case there's no need to recompile but only to relink and having binary builds helps a lot.

> i still think that having the base system on the unstable arch isn't a
> very good idea. i've used the same stuff for quite some time, but i
> found out that it isn't a very good stuff. or at least 6 months ago
> wasn't a good idea.

I've never had serious issues in that regard.  I'd suggest it's because
I /always/ use --update --deep --newuse on my emerge world updates, so
stuff tends to be pretty up to date anyway, and due to regular use of
revdep-rebuild and emerge --depclean to keep the system hygiene level
high.

the problem is always there: major or blocking bugs getting into the  unstable branch after the update  of the package (has happened with dhcpcd for example) that makes gentoo devs mask the package the next day or so. so for people like me that update daily this could be troublesome if it happens on the system packages.

The cure, of course, is a faster machine! =8^)  Gentoo was reasonable
with my old dual Opteron 242, but merges for things such as gcc, glibc,
and DEFINITELY whole desktop updates like KDE, tended to be a chore.  The
upgrade to dual dual-core Opteron 290s, combined with 8 gigs memory (tho
4 gig would do) and putting PORTAGE_TMPDIR on tmpfs, made a HUGE
difference.  Where KDE 3.5 updates, for example, would take ~12 hours
back when I had a gig of memory and no tmpfs, and ~8 hours after
upgrading the memory, I was running the KDE4-svn ebuilds from the
overlay, and could compile all of KDE4 (well, most, I didn't have kdeedu
or kdedevel merged) in ~4 hours with the dual dual-cores and
PORTAGE_TMPDIR on tmpfs with 8 gigs memory, generally < 2 hours with
everything ccached if I did it daily, and often closer to a single hour!

this is a high end machine. opteron is better than a normal athlon x2 in terms of compilation and having 8gb on a server mobo, that differs from normal mobos, is not affordable for every user. my system is about the average one (2ghz processor, 1gb ram, 80gb hdd) for notebooks and quite average one for desktops. remember that nuveau devs still work on athlons or pentium 3 hw, and that hw is not dead yet. your system nowadays is a middle-high end one.

Really.  Those who've not yet had a chance to try quad cores (however you
get them) and a good 4 gigs memory minimum, it really /does/ make running
Gentoo pretty trivial.  A couple years from now when that's a lower end
new system, it's likely Gentoo and other from-source distributions will
see a fresh rise in popularity, because the time differences between
grabbing a binary update and grabbing a from-source update begin to be
pretty trivial, while all the advantages of from source, in particular,
greater control of dependencies without bloat, remain.  At that level,
the admin time, just figuring out what you are going to install, and
dealing with the config updates, etc, is as much a factor as the compile
time.  By the time we reach 8 cores and a full 8 to 16 gig RAM, that
admin time will be the MAJOR factor, with the actual compile time almost
entirely a non-factor, so the advantages of running binary pretty much
disappear while the advantages of running from-source remain as big as
they ever were!

well, this is true for  minor packages, but kdelibs or kdebase for example are still quite big and if you're not a developer you won't go around compiling it everyday or so.

--
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

--
gentoo-amd64@lists.gentoo.org mailing list




--
dott. ing. beso ------=_Part_21909_9295397.1201720007148-- -- gentoo-amd64@lists.gentoo.org mailing list