[gentoo-amd64] eselect problems

[gentoo-amd64] eselect problems

[Mark Knecht]

Anyone else seen this? Any solutions?

Thanks,
Mark

lightning ~ # emerge portage
Calculating dependencies... done!
>>> Verifying ebuild Manifests...
>>> starting parallel fetching pid 27419

>>> Emerging (1 of 3) app-admin/eselect-1.0.11-r1 to /
 * eselect-1.0.11.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                 [ ok ]
 * checking ebuild checksums ;-) ...                                      [ ok ]
 * checking auxfile checksums ;-) ...                                     [ ok ]
 * checking miscfile checksums ;-) ...                                    [ ok ]
 * checking eselect-1.0.11.tar.bz2 ;-) ...                                [ ok ]
>>> Unpacking source...
>>> Unpacking eselect-1.0.11.tar.bz2 to /var/tmp/portage/app-admin/eselect-1.0.11-r1/work
 * Applying eselect-1.0.11-fix-paludis-command.patch ...                  [ ok ]
>>> Source unpacked.
 * The ebuild phase 'unpack' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313).

 * Messages for package app-admin/eselect-1.0.11-r1:

 * The ebuild phase 'unpack' has exited unexpectedly. This type of behavior
 * is known to be triggered by things such as failed variable assignments
 * (bug #190128) or bad substitution errors (bug #200313).
lightning ~ #

[gentoo-amd64] Re: eselect problems

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0811231331n30ee632cl94db54c8b44cb086@mail.gmail.com, excerpted
below, on  Sun, 23 Nov 2008 13:31:53 -0800:

> * The ebuild phase 'unpack' has exited unexpectedly. This
> * type of behavior is known to be triggered by things such
> * as failed variable assignments (bug #190128) or bad
> * substitution errors (bug #200313).

I don't believe it was this specific ebuild, but I recognize the error 
"This type of behavior..." from some bug reported somewhere that I read 
recently.  Unfortunately I don't remember what it was from, but it's 
likely related, so there has indeed been some similar problems recently.

I know that doesn't help much... maybe after work I'll be able to trace 
it down if nobody else has a better reply by then.

-- 
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

Re: [gentoo-amd64] Re: eselect problems

[Mark Knecht]

On Sun, Nov 23, 2008 at 2:24 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Mark Knecht" <markknecht@gmail.com> posted
> 5bdc1c8b0811231331n30ee632cl94db54c8b44cb086@mail.gmail.com, excerpted
> below, on  Sun, 23 Nov 2008 13:31:53 -0800:
>
>> * The ebuild phase 'unpack' has exited unexpectedly. This
>> * type of behavior is known to be triggered by things such
>> * as failed variable assignments (bug #190128) or bad
>> * substitution errors (bug #200313).
>
> I don't believe it was this specific ebuild, but I recognize the error
> "This type of behavior..." from some bug reported somewhere that I read
> recently.  Unfortunately I don't remember what it was from, but it's
> likely related, so there has indeed been some similar problems recently.
>
> I know that doesn't help much... maybe after work I'll be able to trace
> it down if nobody else has a better reply by then.
>
> --
> 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

Thanks Duncan. Don't put too much effort into it. I poked around in
Bugzilla, couldn't find anything real specific so I filed a bug
report. Probably it will get worked out over the next couple of days
anyway.

The root cause of this is I wanted to emerge the newest version of
Ardour from the pro-audio overlay and ran into a new message about it
being masked by something called EAPI 2 which according to the message
requires a 'newer' version of portage. (No revision given.) That's all
this was about, and there's absoutely no rush to fix it as I'm not
likely to really use Ardour. Just wanted to take a look at what sort
of headway they are making with their feature set so it's really
nothing but pure curiosity.

Cheers,
Mark

[gentoo-amd64] Re: eselect problems

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0811231435y2eea1b1by366c787c983c1089@mail.gmail.com, excerpted
below, on  Sun, 23 Nov 2008 14:35:42 -0800:

> The root cause of this is I wanted to emerge the newest version of
> Ardour from the pro-audio overlay and ran into a new message about it
> being masked by something called EAPI 2 which according to the message
> requires a 'newer' version of portage. (No revision given.) That's all
> this was about, and there's absoutely no rush to fix it as I'm not
> likely to really use Ardour. Just wanted to take a look at what sort of
> headway they are making with their feature set so it's really nothing
> but pure curiosity.

OK.  FWIW, for EAPI-2, you need the new ~arch portage-2.2-rcX series.  
EAPI-2 is allowed in various overlays and now in ~arch, but not in stable 
until a stable portage supports it.  It'll bring a number of new features 
including full set support, per-package use-defaults (previously a USE 
flag could be defaulted to on per profile, but not per package, off being 
the unset default, of course), and IIRC use dependencies (if a package 
requires say C++ support and gcc has been built without it, it must now 
die with an error message telling the user to make the change, with use-
deps, it could force gcc to be recompiled with C++ instead of dying, thus 
avoiding somebody leaving a 200-package emerge going overnight, only to 
come back the next day to find out it stopped with package #2 due to a 
USE dependency death).

So there are some nice things coming in EAPI-2 and a number of packages 
can really use them.  But an EAPI-2 supporting portage, while now in the 
tree, remains unstable, as there are still a few bugs to work out before 
it goes fully stable.  So if you prefer a stable portage, you'll have to 
wait for EAPI-2, and any packages requiring it (which by definition can't 
be stabilized until an EAPI-2 portage is stable too).

-- 
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

Re: [gentoo-amd64] Re: eselect problems

[Mark Knecht]

On Sun, Nov 23, 2008 at 10:26 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Mark Knecht" <markknecht@gmail.com> posted
> 5bdc1c8b0811231435y2eea1b1by366c787c983c1089@mail.gmail.com, excerpted
> below, on  Sun, 23 Nov 2008 14:35:42 -0800:
>
>> The root cause of this is I wanted to emerge the newest version of
>> Ardour from the pro-audio overlay and ran into a new message about it
>> being masked by something called EAPI 2 which according to the message
>> requires a 'newer' version of portage. (No revision given.) That's all
>> this was about, and there's absoutely no rush to fix it as I'm not
>> likely to really use Ardour. Just wanted to take a look at what sort of
>> headway they are making with their feature set so it's really nothing
>> but pure curiosity.
>
> OK.  FWIW, for EAPI-2, you need the new ~arch portage-2.2-rcX series.
> EAPI-2 is allowed in various overlays and now in ~arch, but not in stable
> until a stable portage supports it.  It'll bring a number of new features
> including full set support, per-package use-defaults (previously a USE
> flag could be defaulted to on per profile, but not per package, off being
> the unset default, of course), and IIRC use dependencies (if a package
> requires say C++ support and gcc has been built without it, it must now
> die with an error message telling the user to make the change, with use-
> deps, it could force gcc to be recompiled with C++ instead of dying, thus
> avoiding somebody leaving a 200-package emerge going overnight, only to
> come back the next day to find out it stopped with package #2 due to a
> USE dependency death).
>
> So there are some nice things coming in EAPI-2 and a number of packages
> can really use them.  But an EAPI-2 supporting portage, while now in the
> tree, remains unstable, as there are still a few bugs to work out before
> it goes fully stable.  So if you prefer a stable portage, you'll have to
> wait for EAPI-2, and any packages requiring it (which by definition can't
> be stabilized until an EAPI-2 portage is stable too).
>
> --
> Duncan - List replies preferred.   No HTML msgs.

Thanks Duncan. I basically understand the portage stuff, in the sense
that it's a new feature. I read a few eamils form the portage
developers, etc., and got a sense of some of what it is supposed to
do. that part I'm OK with, as I am, I guess, with the idea that
someone who wrote the Ardour ebuild is requiring these new features.

My real question is what is required to build that portage on an
~amd64 machine so that I can build Ardour? Is anyone on this list
using portage-2.2.x? If so how did they get it to build?

Thanks,
Mark

Re: [gentoo-amd64] Re: eselect problems

[Tonko Mulder]

Op maandag 24-11-2008 om 06:00 uur [tijdzone -0800], schreef Mark
Knecht:
> On Sun, Nov 23, 2008 at 10:26 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> > "Mark Knecht" <markknecht@gmail.com> posted
> > 5bdc1c8b0811231435y2eea1b1by366c787c983c1089@mail.gmail.com, excerpted
> > below, on  Sun, 23 Nov 2008 14:35:42 -0800:
> >
> >> The root cause of this is I wanted to emerge the newest version of
> >> Ardour from the pro-audio overlay and ran into a new message about it
> >> being masked by something called EAPI 2 which according to the message
> >> requires a 'newer' version of portage. (No revision given.) That's all
> >> this was about, and there's absoutely no rush to fix it as I'm not
> >> likely to really use Ardour. Just wanted to take a look at what sort of
> >> headway they are making with their feature set so it's really nothing
> >> but pure curiosity.
> >
> > OK.  FWIW, for EAPI-2, you need the new ~arch portage-2.2-rcX series.
> > EAPI-2 is allowed in various overlays and now in ~arch, but not in stable
> > until a stable portage supports it.  It'll bring a number of new features
> > including full set support, per-package use-defaults (previously a USE
> > flag could be defaulted to on per profile, but not per package, off being
> > the unset default, of course), and IIRC use dependencies (if a package
> > requires say C++ support and gcc has been built without it, it must now
> > die with an error message telling the user to make the change, with use-
> > deps, it could force gcc to be recompiled with C++ instead of dying, thus
> > avoiding somebody leaving a 200-package emerge going overnight, only to
> > come back the next day to find out it stopped with package #2 due to a
> > USE dependency death).
> >
> > So there are some nice things coming in EAPI-2 and a number of packages
> > can really use them.  But an EAPI-2 supporting portage, while now in the
> > tree, remains unstable, as there are still a few bugs to work out before
> > it goes fully stable.  So if you prefer a stable portage, you'll have to
> > wait for EAPI-2, and any packages requiring it (which by definition can't
> > be stabilized until an EAPI-2 portage is stable too).
> >
> > --
> > Duncan - List replies preferred.   No HTML msgs.
> 
> Thanks Duncan. I basically understand the portage stuff, in the sense
> that it's a new feature. I read a few eamils form the portage
> developers, etc., and got a sense of some of what it is supposed to
> do. that part I'm OK with, as I am, I guess, with the idea that
> someone who wrote the Ardour ebuild is requiring these new features.
> 
> My real question is what is required to build that portage on an
> ~amd64 machine so that I can build Ardour? Is anyone on this list
> using portage-2.2.x? If so how did they get it to build?
> 
I run sys-apps/portage-2.2_rc15 
But that just got installed with the updates. Not sure if there are
special requirements or not.
> Thanks,
> Mark
> 

Re: [gentoo-amd64] Re: eselect problems

[Mark Knecht]

On Mon, Nov 24, 2008 at 6:12 AM, Tonko Mulder <tonko.mulder@gmail.com> wrote:
> Op maandag 24-11-2008 om 06:00 uur [tijdzone -0800], schreef Mark
> Knecht:
>> On Sun, Nov 23, 2008 at 10:26 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>> > "Mark Knecht" <markknecht@gmail.com> posted
>> > 5bdc1c8b0811231435y2eea1b1by366c787c983c1089@mail.gmail.com, excerpted
>> > below, on  Sun, 23 Nov 2008 14:35:42 -0800:
>> >
>> >> The root cause of this is I wanted to emerge the newest version of
>> >> Ardour from the pro-audio overlay and ran into a new message about it
>> >> being masked by something called EAPI 2 which according to the message
>> >> requires a 'newer' version of portage. (No revision given.) That's all
>> >> this was about, and there's absoutely no rush to fix it as I'm not
>> >> likely to really use Ardour. Just wanted to take a look at what sort of
>> >> headway they are making with their feature set so it's really nothing
>> >> but pure curiosity.
>> >
>> > OK.  FWIW, for EAPI-2, you need the new ~arch portage-2.2-rcX series.
>> > EAPI-2 is allowed in various overlays and now in ~arch, but not in stable
>> > until a stable portage supports it.  It'll bring a number of new features
>> > including full set support, per-package use-defaults (previously a USE
>> > flag could be defaulted to on per profile, but not per package, off being
>> > the unset default, of course), and IIRC use dependencies (if a package
>> > requires say C++ support and gcc has been built without it, it must now
>> > die with an error message telling the user to make the change, with use-
>> > deps, it could force gcc to be recompiled with C++ instead of dying, thus
>> > avoiding somebody leaving a 200-package emerge going overnight, only to
>> > come back the next day to find out it stopped with package #2 due to a
>> > USE dependency death).
>> >
>> > So there are some nice things coming in EAPI-2 and a number of packages
>> > can really use them.  But an EAPI-2 supporting portage, while now in the
>> > tree, remains unstable, as there are still a few bugs to work out before
>> > it goes fully stable.  So if you prefer a stable portage, you'll have to
>> > wait for EAPI-2, and any packages requiring it (which by definition can't
>> > be stabilized until an EAPI-2 portage is stable too).
>> >
>> > --
>> > Duncan - List replies preferred.   No HTML msgs.
>>
>> Thanks Duncan. I basically understand the portage stuff, in the sense
>> that it's a new feature. I read a few eamils form the portage
>> developers, etc., and got a sense of some of what it is supposed to
>> do. that part I'm OK with, as I am, I guess, with the idea that
>> someone who wrote the Ardour ebuild is requiring these new features.
>>
>> My real question is what is required to build that portage on an
>> ~amd64 machine so that I can build Ardour? Is anyone on this list
>> using portage-2.2.x? If so how did they get it to build?
>>
> I run sys-apps/portage-2.2_rc15
> But that just got installed with the updates. Not sure if there are
> special requirements or not.

Thanks Tonko.

Watch out for a portage downgrade if you haven't unmasked 2.2-rcX.
Reading on the 32-bit list there are others who are getting downgraded
due to developers wanting more testing on 2.1...

Cheers,
Mark

Re: [gentoo-amd64] Re: eselect problems

[Drake Donahue]

----- Original Message ----- 
From: "Mark Knecht" <markknecht@gmail.com>
To: <gentoo-amd64@lists.gentoo.org>
Sent: Monday, November 24, 2008 9:35 AM
Subject: Re: [gentoo-amd64] Re: eselect problems


> On Mon, Nov 24, 2008 at 6:12 AM, Tonko Mulder <tonko.mulder@gmail.com> 
> wrote:
>> Op maandag 24-11-2008 om 06:00 uur [tijdzone -0800], schreef Mark
>> Knecht:
>>> On Sun, Nov 23, 2008 at 10:26 PM, Duncan <1i5t5.duncan@cox.net> wrote:
>>> > "Mark Knecht" <markknecht@gmail.com> posted
>>> > 5bdc1c8b0811231435y2eea1b1by366c787c983c1089@mail.gmail.com, excerpted
>>> > below, on  Sun, 23 Nov 2008 14:35:42 -0800:
>>> >
>>> >> The root cause of this is I wanted to emerge the newest version of
>>> >> Ardour from the pro-audio overlay and ran into a new message about it
>>> >> being masked by something called EAPI 2 which according to the 
>>> >> message
>>> >> requires a 'newer' version of portage. (No revision given.) That's 
>>> >> all
>>> >> this was about, and there's absoutely no rush to fix it as I'm not
>>> >> likely to really use Ardour. Just wanted to take a look at what sort 
>>> >> of
>>> >> headway they are making with their feature set so it's really nothing
>>> >> but pure curiosity.
>>> >
>>> > OK.  FWIW, for EAPI-2, you need the new ~arch portage-2.2-rcX series.
>>> > EAPI-2 is allowed in various overlays and now in ~arch, but not in 
>>> > stable
>>> > until a stable portage supports it.  It'll bring a number of new 
>>> > features
>>> > including full set support, per-package use-defaults (previously a USE
>>> > flag could be defaulted to on per profile, but not per package, off 
>>> > being
>>> > the unset default, of course), and IIRC use dependencies (if a package
>>> > requires say C++ support and gcc has been built without it, it must 
>>> > now
>>> > die with an error message telling the user to make the change, with 
>>> > use-
>>> > deps, it could force gcc to be recompiled with C++ instead of dying, 
>>> > thus
>>> > avoiding somebody leaving a 200-package emerge going overnight, only 
>>> > to
>>> > come back the next day to find out it stopped with package #2 due to a
>>> > USE dependency death).
>>> >
>>> > So there are some nice things coming in EAPI-2 and a number of 
>>> > packages
>>> > can really use them.  But an EAPI-2 supporting portage, while now in 
>>> > the
>>> > tree, remains unstable, as there are still a few bugs to work out 
>>> > before
>>> > it goes fully stable.  So if you prefer a stable portage, you'll have 
>>> > to
>>> > wait for EAPI-2, and any packages requiring it (which by definition 
>>> > can't
>>> > be stabilized until an EAPI-2 portage is stable too).
>>> >
>>> > --
>>> > Duncan - List replies preferred.   No HTML msgs.
>>>
>>> Thanks Duncan. I basically understand the portage stuff, in the sense
>>> that it's a new feature. I read a few eamils form the portage
>>> developers, etc., and got a sense of some of what it is supposed to
>>> do. that part I'm OK with, as I am, I guess, with the idea that
>>> someone who wrote the Ardour ebuild is requiring these new features.
>>>
>>> My real question is what is required to build that portage on an
>>> ~amd64 machine so that I can build Ardour? Is anyone on this list
>>> using portage-2.2.x? If so how did they get it to build?
>>>
>> I run sys-apps/portage-2.2_rc15
>> But that just got installed with the updates. Not sure if there are
>> special requirements or not.
>
> Thanks Tonko.
>
> Watch out for a portage downgrade if you haven't unmasked 2.2-rcX.
> Reading on the 32-bit list there are others who are getting downgraded
> due to developers wanting more testing on 2.1...
>
> Cheers,
> Mark
>
The wisdom of making currently existing and useful packages depend on some 
future incomplete package management system (so that updates become arduous 
and/or impossible)?? Anyone discovered a way to cope with 'masked by eapx '? 
sys-apps/portage-2.2_rc15 did not relieve a 'masked by eap2' .... 

[gentoo-amd64] Re: eselect problems

[Duncan]

"Drake Donahue" <donahue95@comcast.net> posted
414A2586925347C7BCFA0A784EC2A8FE@iwillxp333, excerpted below, on  Mon, 24
Nov 2008 12:19:04 -0500:

> The wisdom of making currently existing and useful packages depend on
> some future incomplete package management system (so that updates become
> arduous and/or impossible)?? Anyone discovered a way to cope with
> 'masked by eapx '? sys-apps/portage-2.2_rc15 did not relieve a 'masked
> by eap2' ....

It should be 2.2_rc16, now.  rc15 has a circular logic bug on unsolved 
dependencies.

But unless you happened to hit that bug, EAPI-2 should have worked, at 
least for anything in-tree and at least ~arch unmasked.  I'm not sure why 
it wouldn't have and if it didn't it's certainly a bug, either in the 
package or in portage.  Of course, overlays are an entirely different 
matter.  In part, they are /intended/ to allow experimentation, and for 
the more experimental overlays, all bets and all guarantees are off.  See 
below.

But to answer your question, the EAPI restrictions work in stages, as 
follows:

(1) Overlays can use whatever weird features they want, including ones 
only (for example) paludis supports, not portage at all.  That's one of 
the reasons they are there, to allow the testing of experimental features.

(2) In ordered to be unmasked to ~arch in the tree, the features used 
must be in a Gentoo council approved EAPI.  The council has decided that 
it will only approve an EAPI (E-API, e being the traditional Gentoo 
prefix for package manager stuff and API having the traditional meaning) 
once it is concretely defined such that all three package managers agree 
on the definition, and when the official Gentoo PM, portage, supports it, 
at the same ~arch level as the packages depending on that EAPI.

(3) No package using a new EAPI can go stable until the official package 
manager, portage, supports it in a stable version as well.

If you are using overlay ebuilds, it's assumed you know how experimental 
that overlay is allowed to be and that you are willing to run an equally 
experimental package manager implementation of whatever features it 
uses.  Gentoo neither can nor does attempt to make guarantees at that 
level.  If you are using ~arch packages, there are limited guarantees 
attempted, but as the express purpose of ~arch is to allow packages 
intended for stable to be tested, but it's understood to be unstable and 
thus there will be bugs from time to time.  Again, if you choose to use 
such packages, it's assumed you have your reasons and can manage to live 
with the consequences of the bugs that will occur.

If you don't like those terms, only use stable, but be prepared to live 
with packages somewhat behind the times.  In some cases, particularly 
with new hardware or with software that just added a very popular new 
feature, this will mean you'll simply do without support if you require 
that hardware support or feature to use the package, until the package 
works its way thru the system and is stabilized.

Personally, I default to ~arch, and unmask hard-masked packages either in-
tree or from various overlays from time to time as well.  But in general, 
I'm prepared for them to fail once in awhile, and to spend sometimes 
significant time tracing and reporting bugs, then working around them or 
rolling back to an earlier version without the bug, should I need the 
bugged functionality.  But YMMV definitely applies in this area, and 
while I'd not be satisfied running what I'd consider long outdated 
versions that may be the latest stable in many cases, other people may 
prefer that stability even if it does mean being maybe a year behind at 
times, possibly even more in some cases.

-- 
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

Re: [gentoo-amd64] Re: eselect problems

[Mark Knecht]

On Mon, Nov 24, 2008 at 11:59 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Drake Donahue" <donahue95@comcast.net> posted
> 414A2586925347C7BCFA0A784EC2A8FE@iwillxp333, excerpted below, on  Mon, 24
> Nov 2008 12:19:04 -0500:
>
>> The wisdom of making currently existing and useful packages depend on
>> some future incomplete package management system (so that updates become
>> arduous and/or impossible)?? Anyone discovered a way to cope with
>> 'masked by eapx '? sys-apps/portage-2.2_rc15 did not relieve a 'masked
>> by eap2' ....
>
> It should be 2.2_rc16, now.  rc15 has a circular logic bug on unsolved
> dependencies.
>
> But unless you happened to hit that bug, EAPI-2 should have worked, at
> least for anything in-tree and at least ~arch unmasked.  I'm not sure why
> it wouldn't have and if it didn't it's certainly a bug, either in the
> package or in portage.  Of course, overlays are an entirely different
> matter.  In part, they are /intended/ to allow experimentation, and for
> the more experimental overlays, all bets and all guarantees are off.  See
> below.
>
> But to answer your question, the EAPI restrictions work in stages, as
> follows:
>
> (1) Overlays can use whatever weird features they want, including ones
> only (for example) paludis supports, not portage at all.  That's one of
> the reasons they are there, to allow the testing of experimental features.
>
> (2) In ordered to be unmasked to ~arch in the tree, the features used
> must be in a Gentoo council approved EAPI.  The council has decided that
> it will only approve an EAPI (E-API, e being the traditional Gentoo
> prefix for package manager stuff and API having the traditional meaning)
> once it is concretely defined such that all three package managers agree
> on the definition, and when the official Gentoo PM, portage, supports it,
> at the same ~arch level as the packages depending on that EAPI.
>
> (3) No package using a new EAPI can go stable until the official package
> manager, portage, supports it in a stable version as well.
>
> If you are using overlay ebuilds, it's assumed you know how experimental
> that overlay is allowed to be and that you are willing to run an equally
> experimental package manager implementation of whatever features it
> uses.  Gentoo neither can nor does attempt to make guarantees at that
> level.  If you are using ~arch packages, there are limited guarantees
> attempted, but as the express purpose of ~arch is to allow packages
> intended for stable to be tested, but it's understood to be unstable and
> thus there will be bugs from time to time.  Again, if you choose to use
> such packages, it's assumed you have your reasons and can manage to live
> with the consequences of the bugs that will occur.
>
> If you don't like those terms, only use stable, but be prepared to live
> with packages somewhat behind the times.  In some cases, particularly
> with new hardware or with software that just added a very popular new
> feature, this will mean you'll simply do without support if you require
> that hardware support or feature to use the package, until the package
> works its way thru the system and is stabilized.
>
> Personally, I default to ~arch, and unmask hard-masked packages either in-
> tree or from various overlays from time to time as well.  But in general,
> I'm prepared for them to fail once in awhile, and to spend sometimes
> significant time tracing and reporting bugs, then working around them or
> rolling back to an earlier version without the bug, should I need the
> bugged functionality.  But YMMV definitely applies in this area, and
> while I'd not be satisfied running what I'd consider long outdated
> versions that may be the latest stable in many cases, other people may
> prefer that stability even if it does mean being maybe a year behind at
> times, possibly even more in some cases.
>
> --
> 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
>
>
>

Re: [gentoo-amd64] Re: eselect problems

[Mark Knecht]

Sorry about previous send with no additions. Bad fingers this
afternoon I guess...

On Mon, Nov 24, 2008 at 11:59 AM, Duncan <1i5t5.duncan@cox.net> wrote:
> "Drake Donahue" <donahue95@comcast.net> posted
> 414A2586925347C7BCFA0A784EC2A8FE@iwillxp333, excerpted below, on  Mon, 24
> Nov 2008 12:19:04 -0500:
>
>> The wisdom of making currently existing and useful packages depend on
>> some future incomplete package management system (so that updates become
>> arduous and/or impossible)?? Anyone discovered a way to cope with
>> 'masked by eapx '? sys-apps/portage-2.2_rc15 did not relieve a 'masked
>> by eap2' ....
>
> It should be 2.2_rc16, now.  rc15 has a circular logic bug on unsolved
> dependencies.
>
<SNIP>
>
> Personally, I default to ~arch, and unmask hard-masked packages either in-
> tree or from various overlays from time to time as well.

Where do you do this? In /etc/make.conf? I've never run a machine like
that but would be interested in at least seeing how many packages this
machine would have to rebuild if I went there.

Also, when you say '~arch' on this list do you really mean ~amd64, or
is there a real ~arch that I've not learned about?

Generally I've always run stable and then never shied away from having
a larger set of file in my package.keywords file to get what I think I
want to run.

> But in general,
> I'm prepared for them to fail once in awhile, and to spend sometimes
> significant time tracing and reporting bugs, then working around them or
> rolling back to an earlier version without the bug, should I need the
> bugged functionality.  But YMMV definitely applies in this area, and
> while I'd not be satisfied running what I'd consider long outdated
> versions that may be the latest stable in many cases, other people may
> prefer that stability even if it does mean being maybe a year behind at
> times, possibly even more in some cases.
>
> --
> Duncan - List replies preferred.   No HTML msgs.

I don't think that running 'stable' anymore really means stable.
package management has (IMO, really) gotten rather arbitrary over the
last 2 years to the extent that I know of multiple people who have
left the distro because stable packages are really broken. It's hard
on some people with certain workload models (say a professional
recording studio) to run stable, do updates, find new software is
broken, and then have to downgrade. Lost time is lost money. I know of
at least 4 that have moved onto other prepacked distros in the last
year. Disappointing.

Anyway, back on topic. I managed to build portage-2.2_rc16 today and
now have the option of building ardour-2.7. Not sure I'm gonna do it
though as I then have 2 files blocking, one having to do with Gnome
itself and I had to unmask a whole boatload of packages to get to the
point that I found that:

media-sound/ardour ~amd64
media-sound/jack-audio-connection-kit ~amd64
media-libs/aubio ~amd64
dev-cpp/gtkmm ~amd64
dev-cpp/glibmm ~amd64
dev-libs/glib ~amd64
dev-cpp/pangomm ~amd64
x11-libs/gtk+ ~amd64
x11-libs/pango ~amd64
x11-libs/cairo ~amd64
x11-libs/pixman ~amd64


lightning ~ # emerge -pvDuN world

These are the packages that would be merged, in order:

Calculating dependencies... done!

<SNIP>

[blocks b     ] <dev-cpp/gtkmm-2.13:2.4 ("<dev-cpp/gtkmm-2.13:2.4" is
blocking dev-cpp/pangomm-2.14.1)
[blocks B     ] <gnome-base/gail-1000 ("<gnome-base/gail-1000" is
blocking x11-libs/gtk+-2.14.4)

Total: 10 packages (9 upgrades, 1 new), Size of downloads: 46,253 kB
Conflict: 2 blocks (1 unsatisfied)
lightning ~ #

Not sure this is worth the effort, at least until the weekend maybe.

Thanks for your help. At least I got past the issue with portage.

Cheers,
Mark

[gentoo-amd64] Re: eselect problems

[Duncan]

"Mark Knecht" <markknecht@gmail.com> posted
5bdc1c8b0811241446s7b7b01e7qba78f4e6de060a38@mail.gmail.com, excerpted
below, on  Mon, 24 Nov 2008 14:46:35 -0800:

>> Personally, I default to ~arch, and unmask hard-masked packages either
>> in- tree or from various overlays from time to time as well.
> 
> Where do you do this? In /etc/make.conf? I've never run a machine like
> that but would be interested in at least seeing how many packages this
> machine would have to rebuild if I went there.

Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable 
amd64 as well, as shown by an emerge --info) in /etc/make.conf.  You'd be 
surprised at how far out of date stable arch is in some cases.  Of course 
in other cases, generally mature and real slow moving packages, the 
latest version available has long been stable on most or all archs (see 
below).

> Also, when you say '~arch' on this list do you really mean ~amd64, or is
> there a real ~arch that I've not learned about?

~arch (arch being short for machine-architecture, with the stable 
equivalent then being just arch or simply stable) is simply the generic 
term for what on Debian would be (AFAIK) testing, for any machine type, 
amd64/x86/ppc/ppc64/mips/superh(sh)/whatever, altho some of the lower use 
ones are classed as experimental and only get ~arch.  They don't get full 
stable as there's simply not enough devs and ATs on those archs to keep 
up with stable testing.

> Generally I've always run stable and then never shied away from having a
> larger set of file in my package.keywords file to get what I think I
> want to run.

With ~arch by default, you normally have very few packages listed in 
package.keywords.  There /may/ be a few individual packages that you 
choose to stay with stable on, but at least here, I don't use 
package.keywords for that but rather, package.mask, and mask whatever 
individual version I'm having problems with, thereby forcing portage back 
to a previous version, whether that's stable or an earlier ~arch version.

Another bonus of ~arch is that you very seldom ever have a security 
upgrade to worry about (I've seen one in >4 years), because most of the 
time you're well past the afflicted versions in any case.  At least 
that's the case if you also do --deep by default when you upgrade, as I 
do.

The parallel down-side, however, is that there's quite a bit more package 
churn on ~arch -- a package may go thru several -r versions and 
occasionally even several upstream releases for ~arch, before one is 
actually demonstrated to be stable enough to be keyworded straight arch.

The packages I /do/ have listed in package.keywords are usually there so 
I can keyword them something else, perhaps ** if I'm testing a package 
that has no arch keywords at all yet (KEYWORDS="", the empty set). or 
occasionally x86 if I'm testing something that's keyworded for it but has 
no amd64 keyword at all, ~ or not.  In theory it could be something else 
too, but it's relatively unlikely to be needed as long as x86 and amd64 
are the majority archs.

> I don't think that running 'stable' anymore really means stable. package
> management has (IMO, really) gotten rather arbitrary over the last 2
> years to the extent that I know of multiple people who have left the
> distro because stable packages are really broken. It's hard on some
> people with certain workload models (say a professional recording
> studio) to run stable, do updates, find new software is broken, and then
> have to downgrade. Lost time is lost money. I know of at least 4 that
> have moved onto other prepacked distros in the last year. Disappointing.

I've heard that before, but as I run ~arch by default, I obviously have 
no personal experience to go on.  What I believe happens is that devs by 
definition will be running ~arch on many of their boxes, and that while 
they are supposed to and I'm sure do actually test on a stable box before 
marking stable, the test sample size is by practical reality relatively 
small, and sometimes, when the package hits the larger stable user base, 
there /will/ be the occasional configuration that breaks, because there 
was simply no case of it in the tested sample base.

Of course, there's also the occasional pure mistake, plain and simple, 
where some dev goofed and something got marked stable that shouldn't have 
been.

But as I was explaining earlier, other than the occasional simply broken 
config that's normally caught before a package gets anywhere near stable, 
I believe someone running ~arch and regularly updating --deep is probably 
less likely to run into issues than somebody running who knows /how/ old 
and stale deep dependencies that simply haven't been upgraded in ages, 
because nothing required it, the user is on stable so they're behind 
upstream's development edge in any case, and the user normally doesn't 
use --deep when he does his upgrades so the dependencies tend to stay at 
the absolute minimum version necessary to work, which can as I said be 
years behind what the upstream provider of the package is working on, and 
broken in all sorts of ways against current versions of gcc and glibc and 
the various dependency libraries.

Here's a bit of the upstream perspective.  I'm not a dev per se but I'm 
relatively closely involved with the pan (nntp/newsgroup client) 
upstream, being AFAIK the oldest and most active regular on the pan user 
and developer lists.  Most users on the lists will be using the latest 
version or close to it, and when a new version of gcc or glib or gtk 
comes out, we'll be working on patches to get pan working with the 
latest.  Someone with better development skills than me usually gets a 
working patch relatively quickly, and we all submit it to our various 
distributions (I submit to Gentoo, of course, and have a working 
relationship with eva@gentoo, the Gentoo dev that usually handles pan) 
and the pan/gnome bugzilla itself, so Charles (the actual developer) can 
incorporate it in the next release when he gets around to doing one.  

Then six months or a year later, we get people coming in with the same 
problems we dealt with back then and have by now forgotten the details 
of, asking how to get two-year-old pan versions to compile.  That's not 
even counting the ones still using the old and no longer updated pan 
0.14.x C language version, when upstream pan has for /years/ now been an 
entirely recoded in C++ version, starting with 0.90 and now on 0.133.  
(To be fair, the new C++ version hasn't had an official "stable" release 
upstream yet, but it works better than the old crufty code ever did, the 
old code is now broken on anything like a modern compiler or against 
modern glib or gtk, and despite the lack of an official stable new-code 
version, the old-code is officially unsupported now, with no further 
development taking place.)

So I know first hand from an upstream perspective what it's like trying 
to deal with years outdated "stable" versions.

Then there's the fact that with 0.132 released Aug. 1, 2007, and an 
updated 0.133 released exactly a year later, Aug. 1, 2008, the unpatched 
0.132 as STILL carried by Ubuntu even in their latest 2008.10 release, 
HAS A KNOWN SECURITY VULNERABILITY!  This despite the fact that a patch 
was released in late May, and they've had a security bug open on it, just 
sitting there for nearly that long!  (I personally filed the Gentoo bug 
in late May, the ~arch version was patched within two weeks, and an 
upgrade with the patch was stabilized and GLSA released by July, AFAIK.)  
Needless to say some of us pan upstream regulars are a bit irritated at 
Ubuntu right now, with who knows how many users not only from the 2008.4 
release but now the 2008.10 release as well, left vulnerable to a 
publicly known security bug.

At least Gentoo stable isn't /that/ bad!  We got our updates and the GLSA 
out, and the old/vulnerable versions hard/security masked and then 
removed.  But perhaps you get the idea why I don't find stable a choice 
particularly usable for me personally at least, now.  Of course I'm 
closer to pan upstream than anything else, but knowing what I know about 
stale stable packages often lacking all the fixes (security and 
otherwise) of the latest upstream version with pan, it has only made me 
more of a confirmed ~arch user than I would have been otherwise.

-- 
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

Re: [gentoo-amd64] Re: eselect problems

[Beso]

2008/11/25 Duncan <1i5t5.duncan@cox.net>:
> "Mark Knecht" <markknecht@gmail.com> posted
> 5bdc1c8b0811241446s7b7b01e7qba78f4e6de060a38@mail.gmail.com, excerpted
> below, on  Mon, 24 Nov 2008 14:46:35 -0800:
>
>>> Personally, I default to ~arch, and unmask hard-masked packages either
>>> in- tree or from various overlays from time to time as well.
>>
>> Where do you do this? In /etc/make.conf? I've never run a machine like
>> that but would be interested in at least seeing how many packages this
>> machine would have to rebuild if I went there.
>
> Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable
> amd64 as well, as shown by an emerge --info) in /etc/make.conf.  You'd be
> surprised at how far out of date stable arch is in some cases.  Of course
> in other cases, generally mature and real slow moving packages, the
> latest version available has long been stable on most or all archs (see
> below).
>
if i recall corectly in the past some packages that were under amd64 only needed
also accept keywords amd64 near ~amd64. has this changed lately? usually the
latest includes the former but sometimes when the packages are just amd64 and
no ~amd64 ones i remember that i needed to add amd64 also in the keywords.

>> Generally I've always run stable and then never shied away from having a
>> larger set of file in my package.keywords file to get what I think I
>> want to run.
>
> With ~arch by default, you normally have very few packages listed in
> package.keywords.  There /may/ be a few individual packages that you
> choose to stay with stable on, but at least here, I don't use
> package.keywords for that but rather, package.mask, and mask whatever
> individual version I'm having problems with, thereby forcing portage back
> to a previous version, whether that's stable or an earlier ~arch version.
>
i found out that is better to have a less long package.mask instead of
a long package.unmask.
it's faster to controll the stuff in your pc.

>> I don't think that running 'stable' anymore really means stable. package
>> management has (IMO, really) gotten rather arbitrary over the last 2
>> years to the extent that I know of multiple people who have left the
>> distro because stable packages are really broken. It's hard on some
>> people with certain workload models (say a professional recording
>> studio) to run stable, do updates, find new software is broken, and then
>> have to downgrade. Lost time is lost money. I know of at least 4 that
>> have moved onto other prepacked distros in the last year. Disappointing.
>
> I've heard that before, but as I run ~arch by default, I obviously have
> no personal experience to go on.  What I believe happens is that devs by
> definition will be running ~arch on many of their boxes, and that while
> they are supposed to and I'm sure do actually test on a stable box before
> marking stable, the test sample size is by practical reality relatively
> small, and sometimes, when the package hits the larger stable user base,
> there /will/ be the occasional configuration that breaks, because there
> was simply no case of it in the tested sample base.
>
if there's the lack of testing devs for going into stable i don't
really know if it worths
to continue keeping this distinction. maybe it would be better to have something
like a hardened branch in which to go with only stable and secure
stuff that gets
updated rarely but that can be used as production system. more like the fedora
red hat enterprise approach, where red hat is very stable and not
updated very often
if not for security reasons and fedora that gets the new stuff.

> At least Gentoo stable isn't /that/ bad!  We got our updates and the GLSA
> out, and the old/vulnerable versions hard/security masked and then
> removed.  But perhaps you get the idea why I don't find stable a choice
> particularly usable for me personally at least, now.  Of course I'm
> closer to pan upstream than anything else, but knowing what I know about
> stale stable packages often lacking all the fixes (security and
> otherwise) of the latest upstream version with pan, it has only made me
> more of a confirmed ~arch user than I would have been otherwise.
>
well, glsa sometimes aren't marked right. i still have some glsa that
get out from time to time that
have already been fixed. an example is unace.

-- 
dott. ing. beso

[gentoo-amd64] Re: eselect problems

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560811250316g6a10f8ccoee464fe64c272fa7@mail.gmail.com, excerpted
below, on  Tue, 25 Nov 2008 12:16:56 +0100:

> 2008/11/25 Duncan <1i5t5.duncan@cox.net>:
>> "Mark Knecht" <markknecht@gmail.com> posted
>> 5bdc1c8b0811241446s7b7b01e7qba78f4e6de060a38@mail.gmail.com, excerpted
>> below, on  Mon, 24 Nov 2008 14:46:35 -0800:
>>
>>>> Personally, I default to ~arch, and unmask hard-masked packages
>>>> either in- tree or from various overlays from time to time as well.
>>>
>>> Where do you do this? In /etc/make.conf? I've never run a machine like
>>> that but would be interested in at least seeing how many packages this
>>> machine would have to rebuild if I went there.
>>
>> Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable
>> amd64 as well, as shown by an emerge --info) in /etc/make.conf.  You'd
>> be surprised at how far out of date stable arch is in some cases.  Of
>> course in other cases, generally mature and real slow moving packages,
>> the latest version available has long been stable on most or all archs
>> (see below).
>>
> if i recall corectly in the past some packages that were under amd64
> only needed also accept keywords amd64 near ~amd64. has this changed
> lately? usually the latest includes the former but sometimes when the
> packages are just amd64 and no ~amd64 ones i remember that i needed to
> add amd64 also in the keywords.

I'm not saying it can't happen, but if it does, it's certainly a bug, 
either of the package (not testing the keyword correctly) or of portage 
(not setting it correctly), or possibly of the user (maybe a typo, ~adm64 
instead of ~amd64, say).

Here's what I know:

From my make.conf:
ACCEPT_KEYWORDS="~amd64"

emerge --info |grep ACCEPT
ACCEPT_KEYWORDS="amd64 ~amd64"

So portage is actively adding the amd64 stable keyword, based on the 
~amd64 in make.conf.  It has done so since at least whatever portage was 
around for 2004.1, which is when I started with Gentoo/~amd64.  (As I 
switched from Mandrake Cooker for AMD64, I never even seriously 
considered stable Gentoo/amd64, and have run ~amd64 from day one.)  As I 
said, if it didn't work that way for some package, there was a bug 
somewhere!

Also note the wording in the handbook and the Code Listing 1.1 found here 
(link should be a single line, in case I forget to come back and unwrap 
this before sending or if it wraps on your end):

http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
part=3&chap=3#doc_chap1

>>> Generally I've always run stable and then never shied away from having
>>> a larger set of file in my package.keywords file to get what I think I
>>> want to run.
>>
>> With ~arch by default, you normally have very few packages listed in
>> package.keywords.  There /may/ be a few individual packages that you
>> choose to stay with stable on, but at least here, I don't use
>> package.keywords for that but rather, package.mask, and mask whatever
>> individual version I'm having problems with, thereby forcing portage
>> back to a previous version, whether that's stable or an earlier ~arch
>> version.
>>
> i found out that is better to have a less long package.mask instead of a
> long package.unmask. it's faster to controll the stuff in your pc.

That sentence is rather difficult to parse, here.  I think it's probably 
because English isn't your native language, right?  See if the following 
accurately conveys your intention or if am I still confused?

"I [have] found out that [it] is better to have a short package.mask 
instead of a long package.unmask.  It's more efficient control of the 
stuff on your PC."

If that's your intent, I agree.  I prefer the shorter file version here 
myself.  It's just simpler to manage.

However you're not directly addressing what I was.  Note that I was 
talking about package.keywords as opposed to package.mask, not 
package.unmask, which I didn't mention at all.

I was suggesting that if one has ~arch by default and finds an individual 
package where one wishes to revert to to stable arch, it may be better to 
list the broken ~arch version in package.mask, thus reverting to the 
working arch/stable version, instead of using package.keywords to revert 
to stable.  For one thing, masking an individual version only affects 
that version, not newer versions, and in the next round, it's quite 
possible the ~arch version will be perfectly fine.  If one has created 
the entry in package.keywords, one will still be stuck with it for the 
next version, while if the individual broken version is listed in 
package.mask, the next ~arch release will show up as unmasked again, 
giving one a chance to evaluate whether the problem is fixed or not.  
Hopefully it is.

In practice I don't end up using package.mask very much.  Most of the 
time, if a package doesn't work, I check bugs and if necessary file one, 
but often someone already has a bug filed and there's already a patch 
available for me to apply.  I'll normally do that instead of masking the 
package.  And occasionally I'll leave an update unmerged for a couple 
days if it's broken, hoping either a further update is release or a patch 
appears on the bug (which I've CCed to if I didn't file it myself) that I 
can apply (in my local overlay or whatever) and then merge the package.  

If I put something in package.mask here, it's because it truly is broken 
on my config, perhaps because I often run hard-masked new gcc or 
baselayout/openrc versions or the like, before they even hit ~arch, or 
maybe because I tend to customize my system more than most and the 
package simply was never tested (even upstream) on a system that looked 
like mine before.  In any case, I check for a filed bug and file one 
myself if necessary.  Since that type of bug tends to take somewhat 
longer to fix than the trivial ones, if the package won't compile at all 
or has broken functionality I truly depend on, I'll package.mask that 
version and fall back to an earlier version until the bug is fixed, or in 
some cases I decide whatever customization I had that was breaking things 
isn't worth the trouble and I change it to something that works.

So I usually have a very small package.mask.  Right now there's only one 
entry in it, a permanent one, app-emacs/emerge, because one time I 
accidently double-typed "emerge emerge" and got /very/ confused when 
there actually /was/ a package called "emerge" and it tried to emerge it! 
=:^)  So I keep that entry there to give me a warning I can understand 
(instead of a long list of new packages I didn't expect), if I ever make 
that mistake again.

> if there's the lack of testing devs for going into stable i don't really
> know if it worths to continue keeping this distinction. maybe it would
> be better to have something like a hardened branch in which to go with
> only stable and secure stuff that gets updated rarely but that can be
> used as production system. more like the fedora red hat enterprise
> approach, where red hat is very stable and not updated very often
> if not for security reasons and fedora that gets the new stuff.

Well, keep in mind what you're replying to was written by a guy (myself) 
who doesn't have much personal use for stable.  Some people do, and I 
probably would too if I were running a production server on it.  But... 
Gentoo really does /not/ have an "Enterprise class" stable branch.  Every 
year or so the discussion comes up again on the dev list, and we've had 
devs try to start such a project, and devs leave when it didn't work the 
way they wanted it to.  The problem is that supporting such an ultra-
stable branch, backporting fixes to old versions instead of forcing 
upgrades, etc, requires enormous development and testing resources that 
Gentoo simply doesn't have, and as it's currently structured, IMO will 
never have because it's in conflict with the whole idea behind Gentoo, 
rolling updates and all.

Honestly, while I'll straight up admit I'm biased, I don't really see the 
purpose behind a Gentoo (as opposed to say Red Hat) stable in any case.  
The idea of a compile-your-own, seriously customizable (USE flags, 
CFLAGS), rolling update distribution, fits very well the user that loves 
that sort of customization and control, and sees keeping up to date with 
the latest as a good thing.  This is where Gentoo works best.

But it doesn't fit with the user who needs long term support, who would 
rather keep a known working version and only change the bare minimum to 
get security fixes and the like, who often needs a one-size-fits-all less 
customized install (a known and predictable set of CFLAGS, a known set of 
dependencies that always apply to a given package, etc) so it's efficient 
for third party and proprietaryware (Oracle, for example) folks to 
support them, etc.  That's the domain of the Enterprise distribution, and 
Gentoo's whole structure just doesn't fit.  Now, it certainly WOULD be 
possible for a third party to create a Gentoo BASED Enterprise 
distribution, and that would be great!  However, I'd argue that Gentoo 
itself can't do this, because it's antithetical to the very assumptions 
on which Gentoo is based, and were Gentoo to head that direction, it 
would by definition, lose those qualities for which it is known and which 
attracted many of us to it in the first place.

So as I said, every year or two there's a big discussion on -dev about 
trying to force Gentoo into the Enterprise mold, and unfortunately, every 
year or two when it does, some devs tend to get disillusioned and leave, 
because the rest of the devs resist casting Gentoo in concrete like that, 
and as a result, it'll never be the big money big business distribution 
these disillusioned devs seem to think they want.  But if they wanted 
that, my question is why they're working on Gentoo in the first place, 
when there's far better matches for that ideal.  Let Gentoo do what 
Gentoo does best, and let Red Hat do what Red Hat does best.

While we're at it, the same applies to the usual KDE/GNOME/XFCE/etc wars, 
and the VIM/EMACS wars, and ... and ...  I've come to realize that the 
approaches are just different, neither one "better", altho certainly 
individuals will find one or the other "better" for their individual 
needs.  But GNOME folks complain about the confusing array of 
configuration options available on KDE, and KDE folks complain about the 
crippling lack of configuration options and the "There can be only one 
best way and we know it" philosophy GNOME seems to have at times, and 
what few realize is that it's NOT a wasted duplication of effort, and 
that the GNOME folks wouldn't WANT the KDE folks there breaking their 
precious ONE BEST WAY ideas, and conversely, the KDE folks wouldn't WANT 
the GNOME folks trying to take away all those nice config options we 
like, so it really IS best they keep to their own projects, cooperating 
where they can of course, but still separate projects.  And a parallel 
idea applies to VIM/EMACS, etc.

Let each project do what it does best, and attract the devs and users 
that fit best, and let the alternatives continue to exist and flourish as 
well, so everyone finds a home that works for them, and nobody ends up 
breaking the already working just fine solutions others have developed 
for their own needs/wants niche.

-- 
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] Re: eselect problems

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> Beso <givemesugarr@gmail.com> posted
>>> Yes, I set ACCEPT_KEYWORDS=~amd64 (which automatically includes stable
>>> amd64 as well, as shown by an emerge --info) in /etc/make.conf.  You'd
>>> be surprised at how far out of date stable arch is in some cases.  Of
>>> course in other cases, generally mature and real slow moving packages,
>>> the latest version available has long been stable on most or all archs
>>> (see below).
>>>
>> if i recall corectly in the past some packages that were under amd64
>> only needed also accept keywords amd64 near ~amd64. has this changed
>> lately? usually the latest includes the former but sometimes when the
>> packages are just amd64 and no ~amd64 ones i remember that i needed to
>> add amd64 also in the keywords.
> 
> I'm not saying it can't happen, but if it does, it's certainly a bug, 
> either of the package (not testing the keyword correctly) or of portage 
> (not setting it correctly), or possibly of the user (maybe a typo, ~adm64 
> instead of ~amd64, say).
> 
> Here's what I know:
> 
> From my make.conf:
> ACCEPT_KEYWORDS="~amd64"
> 
> emerge --info |grep ACCEPT
> ACCEPT_KEYWORDS="amd64 ~amd64"
> 
> So portage is actively adding the amd64 stable keyword, based on the 
> ~amd64 in make.conf.  It has done so since at least whatever portage was 
> around for 2004.1, which is when I started with Gentoo/~amd64.  (As I 
> switched from Mandrake Cooker for AMD64, I never even seriously 
> considered stable Gentoo/amd64, and have run ~amd64 from day one.)  As I 
> said, if it didn't work that way for some package, there was a bug 
> somewhere!
> 
> Also note the wording in the handbook and the Code Listing 1.1 found here 
> (link should be a single line, in case I forget to come back and unwrap 
> this before sending or if it wraps on your end):
> 
> http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?
> part=3&chap=3#doc_chap1
> 

To clear up any misconceptions, setting ACCEPT_KEYWORDS is similar to
setting USE - unless the magic keyword "-*" appears, portage will add
the previous contents of ACCEPT_KEYWORDS to the value you set.  As the
amd64 keyword is already set in profiles/arch/amd64/make.defaults, the
final setting ends up as "amd64 ~amd64". If you were to, for some reason
set ACCEPT_KEYWORDS="~x86 ~amd64" in make.conf, the final value would be
"amd64 ~amd64 ~x86" - which is not what you would want.  (I, of course,
strongly recommend NOT doing that, but that is what would result)

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkksVrIACgkQOypDUo0oQOrtoQCgtjfsb8iORJxXSsPut3lqNAlr
iggAoLYLHI55JcoWBC4zrNV1CDwKdF3G
=Y8by
-----END PGP SIGNATURE-----

Re: [gentoo-amd64] Re: eselect problems

[Beso]

2008/11/25 Duncan <1i5t5.duncan@cox.net>:
> Beso <givemesugarr@gmail.com> posted
> d257c3560811250316g6a10f8ccoee464fe64c272fa7@mail.gmail.com, excerpted
> below, on  Tue, 25 Nov 2008 12:16:56 +0100:
>
>>>> Generally I've always run stable and then never shied away from having
>>>> a larger set of file in my package.keywords file to get what I think I
>>>> want to run.
>>>
>>> With ~arch by default, you normally have very few packages listed in
>>> package.keywords.  There /may/ be a few individual packages that you
>>> choose to stay with stable on, but at least here, I don't use
>>> package.keywords for that but rather, package.mask, and mask whatever
>>> individual version I'm having problems with, thereby forcing portage
>>> back to a previous version, whether that's stable or an earlier ~arch
>>> version.
>>>
>> i found out that is better to have a less long package.mask instead of a
>> long package.unmask. it's faster to controll the stuff in your pc.
>
> That sentence is rather difficult to parse, here.  I think it's probably
> because English isn't your native language, right?  See if the following
> accurately conveys your intention or if am I still confused?
>
> "I [have] found out that [it] is better to have a short package.mask
> instead of a long package.unmask.  It's more efficient control of the
> stuff on your PC."
>
it has been written in a hurry at work, while speaking at the phone
with an italian
customer...
so i've spit out a rather difficult to understand sentence.

> However you're not directly addressing what I was.  Note that I was
> talking about package.keywords as opposed to package.mask, not
> package.unmask, which I didn't mention at all.
>
same as before...

> I was suggesting that if one has ~arch by default and finds an individual
> package where one wishes to revert to to stable arch, it may be better to
> list the broken ~arch version in package.mask, thus reverting to the
> working arch/stable version, instead of using package.keywords to revert
> to stable.  For one thing, masking an individual version only affects
> that version, not newer versions, and in the next round, it's quite
> possible the ~arch version will be perfectly fine.  If one has created
> the entry in package.keywords, one will still be stuck with it for the
> next version, while if the individual broken version is listed in
> package.mask, the next ~arch release will show up as unmasked again,
> giving one a chance to evaluate whether the problem is fixed or not.
> Hopefully it is.
>
this works for packages in gentoo. the problem is when the same package
is provided in other overlays. I tend to use quite a big number of overlays
and in that case the package mask is mandatory when you want to mask
a specific version and overlay. sometimes when the version is the same
this is proving difficult with portage. this is one of the reasons that i've
switched to paludis long ago when masking a specific package from an
external overlay wasn't really simple (if the version was the same of the
one present in portage).

> In practice I don't end up using package.mask very much.  Most of the
> time, if a package doesn't work, I check bugs and if necessary file one,
> but often someone already has a bug filed and there's already a patch
> available for me to apply.  I'll normally do that instead of masking the
> package.  And occasionally I'll leave an update unmerged for a couple
> days if it's broken, hoping either a further update is release or a patch
> appears on the bug (which I've CCed to if I didn't file it myself) that I
> can apply (in my local overlay or whatever) and then merge the package.
>
this also applies when i want to mask/unmask stuff from my personal testing
overlay (mainly patches against some build that fails).
also when using masked ebuilds, like the live ones, the use of package.unmask
and sometimes package.mask is quite useful.

> If I put something in package.mask here, it's because it truly is broken
> on my config, perhaps because I often run hard-masked new gcc or
> baselayout/openrc versions or the like, before they even hit ~arch, or
> maybe because I tend to customize my system more than most and the
> package simply was never tested (even upstream) on a system that looked
> like mine before.  In any case, I check for a filed bug and file one
> myself if necessary.  Since that type of bug tends to take somewhat
> longer to fix than the trivial ones, if the package won't compile at all
> or has broken functionality I truly depend on, I'll package.mask that
> version and fall back to an earlier version until the bug is fixed, or in
> some cases I decide whatever customization I had that was breaking things
> isn't worth the trouble and I change it to something that works.
>
my problem is that my bugs are ignored due to --as-needed. now that diego
has started to massively test the --as-needed flag as default maybe would be
useful to go back reposting bugs that i might find. i'm now curently undergoing
a full system backup and automatizing it via rsync and cron and after that i'd
recompile whole world with forced --as-needed and --no-undefined and i
expect quite some issues with kde4, since i still haven't understood if xmlrpc-c
is really broken. so i need a backup of a fully working system before
undergoing
this recompile.

> So I usually have a very small package.mask.  Right now there's only one
> entry in it, a permanent one, app-emacs/emerge, because one time I
> accidently double-typed "emerge emerge" and got /very/ confused when
> there actually /was/ a package called "emerge" and it tried to emerge it!
> =:^)  So I keep that entry there to give me a warning I can understand
> (instead of a long list of new packages I didn't expect), if I ever make
> that mistake again.
>
O_O i didn't know that there was a package named emerge...

>> if there's the lack of testing devs for going into stable i don't really
>> know if it worths to continue keeping this distinction. maybe it would
>> be better to have something like a hardened branch in which to go with
>> only stable and secure stuff that gets updated rarely but that can be
>> used as production system. more like the fedora red hat enterprise
>> approach, where red hat is very stable and not updated very often
>> if not for security reasons and fedora that gets the new stuff.
>
> Well, keep in mind what you're replying to was written by a guy (myself)
> who doesn't have much personal use for stable.  Some people do, and I
> probably would too if I were running a production server on it.  But...
> Gentoo really does /not/ have an "Enterprise class" stable branch.  Every
> year or so the discussion comes up again on the dev list, and we've had
> devs try to start such a project, and devs leave when it didn't work the
> way they wanted it to.  The problem is that supporting such an ultra-
> stable branch, backporting fixes to old versions instead of forcing
> upgrades, etc, requires enormous development and testing resources that
> Gentoo simply doesn't have, and as it's currently structured, IMO will
> never have because it's in conflict with the whole idea behind Gentoo,
> rolling updates and all.
>
well, this also applies to the stable branch. then there are also the keyworded
packages. i know that when gentoo came out this distinction (as it is still now)
it has been a really good one, but still, nowadays when the unstable branch is
as stable as the stable branch, with a big lack of devs, maybe it's
better to think
of dropping one of the 2.

> Honestly, while I'll straight up admit I'm biased, I don't really see the
> purpose behind a Gentoo (as opposed to say Red Hat) stable in any case.
> The idea of a compile-your-own, seriously customizable (USE flags,
> CFLAGS), rolling update distribution, fits very well the user that loves
> that sort of customization and control, and sees keeping up to date with
> the latest as a good thing.  This is where Gentoo works best.
>
it's simple in my opinion. rhel offers a big stability with a lot of
security features
and so on. but it has a downside: it's built on classic and not optimized flags
and the packages that are built are fully built, and not only with the
stuff you
really need. having a branch that has similar features, but it's optimized for
a specific machine and takes full potential from that machine would be a boost.
don't you think so?!

> But it doesn't fit with the user who needs long term support, who would
> rather keep a known working version and only change the bare minimum to
> get security fixes and the like, who often needs a one-size-fits-all less
> customized install (a known and predictable set of CFLAGS, a known set of
> dependencies that always apply to a given package, etc) so it's efficient
> for third party and proprietaryware (Oracle, for example) folks to
> support them, etc.  That's the domain of the Enterprise distribution, and
> Gentoo's whole structure just doesn't fit.  Now, it certainly WOULD be
> possible for a third party to create a Gentoo BASED Enterprise
> distribution, and that would be great!  However, I'd argue that Gentoo
> itself can't do this, because it's antithetical to the very assumptions
> on which Gentoo is based, and were Gentoo to head that direction, it
> would by definition, lose those qualities for which it is known and which
> attracted many of us to it in the first place.
>
then we're back to the point when the distinction between stable and unstable
is still a little useless nowadays. the release time between one
version and the
following is going to decrease as time goes. an example is xorg. just
think of how
many xorg-server versions have been released recently, and from what i've read
the project would be pushed farther form intel that wants a fully featured and
working environment for professional use. which has been the latest stable xorg
ebuild?! or for kde 3.5.7 and superior serie. the time in which it
went stable has
been very high. and the same reduction in time between releases is happening
for other projects as well. i really think that this stable/unstable
division should
really be revised, especially when there's a problem with the lack of
testing devs.

> So as I said, every year or two there's a big discussion on -dev about
> trying to force Gentoo into the Enterprise mold, and unfortunately, every
> year or two when it does, some devs tend to get disillusioned and leave,
> because the rest of the devs resist casting Gentoo in concrete like that,
> and as a result, it'll never be the big money big business distribution
> these disillusioned devs seem to think they want.  But if they wanted
> that, my question is why they're working on Gentoo in the first place,
> when there's far better matches for that ideal.  Let Gentoo do what
> Gentoo does best, and let Red Hat do what Red Hat does best.
>
well, i'm not into starting a flame war for this, but in my opinion is more
sensate doing something similar than continuing with the stable/unstable
distinction, that in the last period doesn't really apply anymore.

> While we're at it, the same applies to the usual KDE/GNOME/XFCE/etc wars,
> and the VIM/EMACS wars, and ... and ...  I've come to realize that the
> approaches are just different, neither one "better", altho certainly
> individuals will find one or the other "better" for their individual
> needs.  But GNOME folks complain about the confusing array of
> configuration options available on KDE, and KDE folks complain about the
> crippling lack of configuration options and the "There can be only one
> best way and we know it" philosophy GNOME seems to have at times, and
> what few realize is that it's NOT a wasted duplication of effort, and
> that the GNOME folks wouldn't WANT the KDE folks there breaking their
> precious ONE BEST WAY ideas, and conversely, the KDE folks wouldn't WANT
> the GNOME folks trying to take away all those nice config options we
> like, so it really IS best they keep to their own projects, cooperating
> where they can of course, but still separate projects.  And a parallel
> idea applies to VIM/EMACS, etc.
>
well, it' s better to have a choice and a battle between them than having one
solution that doesn't progress, or that progresses in a bad way, as happens
on windoze for example.

> Let each project do what it does best, and attract the devs and users
> that fit best, and let the alternatives continue to exist and flourish as
> well, so everyone finds a home that works for them, and nobody ends up
> breaking the already working just fine solutions others have developed
> for their own needs/wants niche.
>
i do agree with this point, but sometime it's better to have some arguing about
new solutions and to try them out. you can always learn something new. as a
little example, i have a friend that is fully convinced that linux is
not capable of
doing what windoze svista would do. i just showed him kde4 with compiz enabled,
put on wow on codeweavers (thanks to the free giveaway offer from some
time ago)
and installed the native enemy territory and he remained stupified. he
didn't believe
that he could do the same things that he could do on windoze in a better way and
more intuively on linux. now he's still staying with his windoze but
he doesn't pretends
anymore that linux is bad and not working. the same could apply for gnome when
speaking of innovative features, or to kde when speaking about eye
candy or too much innovation
all together. everyone should sustain their ideas and show them to the
other part so
that the other one could learn something from it. and i think that
when this happens
everyone gets stronger than before. the same discussion might apply for
microsoft-novell agreement that is has bought a very high
compatibility with office
documents to openoffice 3, so that everyone might continue to use whatever he
likes without really worrying that the others could or couldn't understand them.

-- 
dott. ing. beso

[gentoo-amd64] Re: eselect problems

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560811251519w7f8a0734jc27c23e2bf06404e@mail.gmail.com, excerpted
below, on  Tue, 25 Nov 2008 23:19:40 +0000:

> it has been written in a hurry at work, while speaking at the phone with
> an italian customer...
> so i've spit out a rather difficult to understand sentence.

Yeah, that could do it.  Not a problem... except that it wasn't until I 
actually started trying to deconstruct it as part of my reply that I 
actually made sense out of it.  Before that, I thought it internally 
conflicted with itself and figured I knew where you were trying to go 
with it, but wasn't quite sure.  Even afterward I wasn't sure I had it 
right, thus bringing it up to ensure I did.

... And while I don't understand more than a few words in any language 
other than English, I'm /usually/ pretty good at groking strange word 
ordering and etc, because I've been exposed to quite a variety of 
multiple cultures of /some/ sort or another (plus now archaic English) 
most of my life.  So I'm unaccustomed to not being able to make sense out 
of things, even if the word order is /not/ customary English.  But this 
one I really did get wrong at first.  It was a stumper!

> this works for packages in gentoo. the problem is when the same package
> is provided in other overlays. I tend to use quite a big number of
> overlays and in that case the package mask is mandatory when you want to
> mask a specific version and overlay. sometimes when the version is the
> same this is proving difficult with portage.

Yes.  I've only had that happen a relatively few times, because I only 
use a relatively few overlays.  And when it did happen here, it just 
seemed to work the way I needed it to anyway, so I didn't trouble myself 
with it.  But certainly, once someone's running more than a small handful 
of overlays, it can get "interesting".

> this is one of the reasons that i've switched to paludis

That's one thing the paludis devs have gotten right.  It was designed 
pretty much from the beginning to handle multiple overlays and make 
configuring which one gets used for which packages relatively easy.

> this also applies when i want to mask/unmask stuff from my personal
> testing overlay (mainly patches against some build that fails). also
> when using masked ebuilds, like the live ones, the use of package.unmask
> and sometimes package.mask is quite useful.

I used to do a lot of personal overlay stuff.  Now, I use Ed Catmur's 
portage-patches scripts, which hook into portage and allow one to apply 
one's own set of patches to a specified package.  It works for patching 
with an /etc/portage/patches tree much like the /etc/portage/env/ tree 
that the last few versions of portage have worked with for setting stuff 
like CFLAGS in a package-specific way.  (I only recently realized Ed 
Catmur is the author of udept, which I had merged previously, so he /
should/ be relatively familiar with portage tricks.)

Since I installed those scripts and now use package.keywords to set ~x86 
or whatever for some packages instead of putting them in the overlay and 
adding ~amd64, my personal overlay has remained almost empty.  I had a 
"live" pan ebuild, but eva@gentoo encouraged me to forward it when I 
mentioned it in a bug and it's now in the tree.  I have a copy of the 
amarok-1.4.9999 live ebuild that I needed to modify to install slotted 
and not conflict with the amarok-2/kde4 version, but that's about it.  If 
the patch is to the sources, I use portage-patches and use the existing 
ebuild without changes.  Only if the ebuild itself (or eclass, but that 
hasn't happened in awhile) needs patching, and it can't be handled by say 
setting EXTRA_ECONF in the /etc/portage/env tree either, does it end up 
in my overlay.  And that doesn't happen so often.  Usually it's a sources 
patch, and that can go in the /etc/portage/patches tree, thanks to Ed's 
portage-patches.

> my problem is that my bugs are ignored due to --as-needed. now that
> diego has started to massively test the --as-needed flag as default

Hmm... I've been using --as-needed (in LDFLAGS but not forced in spec 
files) for awhile myself, but haven't seen my bugs ignored with it.  
Maybe it's the type of bugs I file, or the type of packages I end up 
finding bugs in and the devs that maintain them, or the fact that if
I think my custom LDFLAGS (or CFLAGS or still masked gcc version or ...) 
are causing problems, I set them to accepted Gentoo defaults for that 
package using a file in the /etc/portage/env tree, and specifically 
mention in my bug whether that changed the result or not.

One thing's for sure, I've certainly developed a much thicker skin over 
the years, since one of my originally filed bugs got marked INVALID for 
some stupid reason.  I don't just tuck my tail between my legs and go 
home like I used to, tho I've not had occasion to get into a real bug-
status war since that changed.  But my bugs don't generally seem to be 
ignored, either. Some don't get action for awhile, but it's not ignoring, 
it's the "real life" of the assigned dev, and the fact that some of my 
bugs are rather esoteric, so not /that/ system life threatening to 
anything.

But Flameeyes' campaigning on the --as-needed thing is certainly needed.  
I'm very glad he's doing it, as it's something few would have the skills 
to tackle, but at the same time, something he can let his new machine do 
much of the work on, so maybe he doesn't overwork himself so much.

Gentoo's lucky to have someone that talented around, and he doesn't have 
the enormous ego problems a lot of the similarly talented devs seem to 
have.  Unfortunately, like my dad and sister, he seems to be a 
workaholic.  They do great and wonderful things, certainly, but they they 
burn the candle at both ends doing it, and their health suffers as a 
result.  Having that problem in my own family, I recognize it in 
Flameeyes as well, and his frequent hospital trips at such a relatively 
young age concern me.  He's an asset not only to Gentoo, but to the FLOSS 
community in general, and I fear we're going to lose him if he can't 
learn to pace himself.  Fortunately, he seems to have realized that 
himself, now, and has cut back substantially from what he /was/ trying to 
do.

> O_O i didn't know that there was a package named emerge...

I didn't either... until then.  But I learned! =:^)

> well, this also applies to the stable branch. then there are also the
> keyworded packages. i know that when gentoo came out this distinction
> (as it is still now) it has been a really good one, but still, nowadays
> when the unstable branch is as stable as the stable branch, with a big
> lack of devs, maybe it's better to think of dropping one of the 2.

Maybe the next time someone brings up the Enterprise Gentoo idea on the 
dev list, I should counter with the dropping stable idea...  AFAIK the 
last time it came up was early this year, so it should be time for it to 
come up again sometime between this spring and next fall...

But they've already dropped stable keyworks on IIRC mips (but don't quote 
me on that, it may have been a different arch, and I'm too lazy to go 
check my devlist archives ATM), because it just wasn't happening, and 
maintainers were getting seriously annoyed due to having to keep outdated 
and broken packages in the tree as the only stable on that arch.

> it's simple in my opinion. rhel offers a big stability with a lot of
> security features and so on. but it has a downside: it's built on
> classic and not optimized flags and the packages that are built are
> fully built, and not only with the stuff you
> really need. having a branch that has similar features, but it's
> optimized for a specific machine and takes full potential from that
> machine would be a boost. don't you think so?!

Yes.  But the problem tends to be that these Enterprise users need 
support, and for that to be economical, there has to be a reasonably 
large size group on the same packages built with the same set of options 
and CFLAGS.

They can get their support and run their proprietary packages, but to do 
it, the tradeoff is that they gotta accept being a clone, 
one-size-fits-all.  The hard economics of the situation are that as soon 
as you optimize for the hardware you're actually running, and build for 
the dependencies you actually need, you're in a niche that's small enough 
it's simply not economical to support you... at the level of commercial 
support that RHEL's customers demand anyway, or they'd be elsewhere.

Practically speaking, you and I know that in many, perhaps most cases, 
the benefit of such "support" is highly questionable anyway, because 
practically speaking, posting to the relevant list/newsgroup/forum gets 
an answer way faster than paid support is likely to.  And in the cases 
where it doesn't, paid support may fail as well.  And... being open 
source, for the few cases where that paid support does actually mean a 
benefit, it's quite possible a single-shot consultant or developer job 
could be funded to address that specific issue, customized solution, for 
roughly the same money but in less time than than the paid support.

But regardless, that doesn't provide someone else to point the finger at 
and save someone's a**, and... practically speaking, RHEL DOES pay a lot 
of paychecks for full-time FLOSS developers, that would at best be part 
time if it weren't for /someone/ deciding they needed that sort of 
support enough to pay the big bucks for it.

> then we're back to the point when the distinction between stable and
> unstable is still a little useless nowadays. the release time between
> one version and the following is going to decrease as time goes. an
> example is xorg. just think of how many xorg-server versions have been
> released recently, and from what i've read the project would be pushed
> farther form intel that wants a fully featured and working environment
> for professional use. which has been the latest stable xorg ebuild?!

xorg is an interesting problem, not in the least because it has a very 
clear yet politically unpalatable solution, simply ignore users who chose 
hardware vendors whose only real competitive features are only enabled by 
proprietaryware drivers.  nVidia, and to a lessor extent ATI but that 
one's being solved as we speak, are, simply put, holding xorg development 
hostage to the rate at which they develop their proprietary drivers to 
match.  The logical thing to do would be to let xorg development and 
those user who have hardware with freedomware drivers continue their 
progress apace, and let the nVidia users be stuck on the two-years-
outdated or whatever proprietary development model they've chosen to 
support with their buying dollars.

Actually, if you look at it, that's gotta be one of the reasons Intel is 
pushing xorg development so hard.  It has a competitive advantage in that 
it's hardware, while not as full featured hardware-wise, has native 
driver support for the latest whiz-bang xorg features right off the 
blocks, leaving the proprietaryware folks sucking dust, and it's not 
above trying to exploit it.  AMD, who needs the Linux users far more than 
Intel does, was facing the very real prospect of being practically locked 
out of the Linux market due to Intel's Linux cooperation, and had no 
choice but to respond, first by buying a graphics maker so it wasn't 
locked out due to the proprietaryware actions of third parties, and then 
by opening up ATI's graphics to the same extent, or actually even 
further, pushing Intel.

But the gamers and their preferred nVidia proprietaryware are continuing 
to hold things back, at least as far as stable support, and not just for 
Gentoo.  All of the big distributions are facing the problem, as are 
Dell, Acer, Asus, and other OEMs now shipping Linux kit in some volume.  
No major distro can afford to cut off the nVidia user market share, so 
none of them can afford to ship a new xorg no matter how far behind their 
current version is, until nVidia deigns to support a newer xorg with 
their proprietary driver.  And $deity have pity on the poor distrib that 
has the luck of having nVidia release a driver just after they've frozen 
the repository to all bug bug fixes in preparation for a new release, 
because now they'll be shipping with an outdated nVidia driver AND xorg, 
and can't really upgrade either one except as options, without delaying 
release another month or two to test the new xorg with everything.  And 
if the major distros can't ship it, then the OEMs basing their own 
distribs on them can't ship it, even if they're using Intel hardware that 
could really benefit from the newer xorg.

Fortunately with the AMD purchase of ATI and its subsequent switch back 
away from the dark side, 2009 seems likely to resolve this.  The 
distributions and hardware OEMs both are getting increasingly impatient 
with nVidia, and with Intel support right there and AMD/ATI/Radeon 
support coming on fast, 2009 looks likely to be the year nVidia either 
reverses itself as well, or regardless, starts losing its ability to hold 
things back.

Bringing that all back around to our discussion at hand, for other 
distributions, that'll probably mean shipping a more modern xorg, with an 
optional stale xorg just to support nVidia users, and a * on their 
feature list with an "nVidia users" small-print disclaimer.  KDE's not a 
distribution, but it has already taken that tact by choosing not to 
support nVidia proprietary driver users at full feature strength some of 
the time.

Gentoo...  will probably either end up taking a similar position with 
stable, telling nVidia users to mask the newest stable until nVidia gets 
off their a**, or will continue to let stable xorg molder, updating it 
only when nVidia deigns to allow it by updating their proprietaryware, 
meanwhile forcing more and more users who want decently current features 
to either highly package.keyworded systems, or to fully ~arch systems.

Hopefully either nVidia or their proprietaryware driver users get a clue, 
but I'm not holding my breath...

> for kde 3.5.7 and superior serie. the time in which it went stable has
> been very high. and the same reduction in time between releases is
> happening for other projects as well. i really think that this
> stable/unstable division should really be revised, especially when
> there's a problem with the lack of testing devs.

KDE... has been a problem for Gentoo of late.  Well, KDE4 has been a 
problem for everyone, not just Gentoo, but Gentoo had problems before 
that, as you mentioned, from 3.5.x.

The real problem for Gentoo has been the size of KDE... and the devs on 
the project.  Losing developers, and before their loss, loss of 
cooperation with the rest of Gentoo, due to an inability to work well 
with others... hurts any project.  There are certainly two sides to the 
story and I'm not close enough to it nor do I have any desire to pick 
sides, so I won't, but the fact is, whoever was to blame or whether it 
was just the way things had to be, that loss /hurt/.  We're lucky a bunch 
of users got involved in the overlay work, or Gentoo basically wouldn't 
/have/ a modern KDE, either 3.5 or 4.x series, at this point.

Hopefully that's all behind us and KDE can become a thriving healthy 
project once again.  As I said, I'm a bit far from the action, but that 
influx of new blood, as well as some developers from other areas putting 
on another hat, has seemed to help, and the major teething problems with 
the switch to the 4.x series seem to be over, so I'm optimistic.

Otherwise, much as I hate to since Gentoo otherwise seems about the ideal 
fit for me personally, I may end up having to ultimately switch to 
something else (assuming KDE4.2 finally gets the kde4 act together 
upstream, as they've been promising, or maybe kde will be what I end up 
dropping), or perhaps more likely, simply switch to kde upstream directly 
for KDE stuff.

But none of the other really big projects seem quite as bad as Gentoo/kde 
and Gentoo/xorg.  In particular, toolchain seems to still be quite 
functional, and the PM side is strong enough it's supporting three 
thriving PM!  What about GNOME and XFCE?  I've not /read/ of anything so 
majorly wrong with those projects and from outside, they've seemed much 
smoother, but unless GNOME reverses course with gnome3, it's not for me, 
and xfce... well, I guess I've never seriously looked at it, but I've 
always thought of it as not as full featured as I like... and my hardware 
certainly isn't the issue it seems to be for a lot of xfce users.

For everything else, at least for desktop use, it doesn't seem to me that 
stable lagging a bit should be a serious problem.  If someone needs codec 
support only in a new media-* package, unlike xorg or toolchain or the 
desktop environment, they can package.keyword it without threatening the 
stability of either the computer itself or at least their entire desktop.

>> While we're at it, the same applies to the usual KDE/GNOME/XFCE/etc
>> wars, and the VIM/EMACS wars, and ... and ...  I've come to realize
>> that the approaches are just different, neither one "better", altho
>> certainly individuals will find one or the other "better" for their
>> individual needs.

> well, it' s better to have a choice and a battle between them than
> having one solution that doesn't progress, or that progresses in a bad
> way, as happens on windoze for example.

Exactly.  Especially when "progress" as defined by some is "regression" 
as defined by others.  When that's the case, as it is for example with 
the proliferation of user accessible controls on KDE as compared to 
forced conformance to the "One True Way" (tm) on GNOME, it's /better/ to 
have separate projects, and far from hurting each other, they keep the 
devs who might otherwise cause problems and needless infighting on the 
other alternative, working on their preferred alternative instead.  Where 
it's possible and convenient, they can always cooperate, and 
freedesktop.org has been very good at bringing that with its various 
hosted projects, while letting the desktop projects otherwise pull in 
their opposing directions without hurting anyone, and in particular, 
without hurting the interests of the wider FLOSS community.  Why so few 
see it and calls for "One True Desktop" (tm) are so common, I don't know, 
except that those folks must still be thinking the "One True MS Way" (tm).

> as a little example, i have a friend that is fully convinced that linux
> is not capable of doing what windoze svista would do. i just showed him
> kde4 with compiz enabled, put on wow on codeweavers (thanks to the free
> giveaway offer from some time ago) and installed the native enemy
> territory and he remained stupified. he didn't believe
> that he could do the same things that he could do on windoze in a better
> way and more intuively on linux. now he's still staying with his windoze
> but he doesn't pretends anymore that linux is bad and not working.

Some people like the security and comfort "Big Brother" (tm) provides...

I could go off on a US political tangent here, or for that matter, on a 
big bad MS tangent, but I won't...  The big bad nVidia bit above is 
enough for this post. =:^)

> the same could apply for gnome when speaking of innovative features,
> or to kde when speaking about eye candy or too much innovation all
> together. everyone should sustain their ideas and show them to the
> other part so that the other one could learn something from it. and i
> think that when this happens everyone gets stronger than before.

That's what's nice about choice and the FLOSS community way of developing 
a bunch of competing solutions in parallel.  That cross-pollination is 
not just allowed, but actively encouraged! =:^) 

> the same discussion might apply for microsoft-novell agreement that is
> has bought a very high compatibility with office
> documents to openoffice 3, so that everyone might continue to use
> whatever he likes without really worrying that the others could or
> couldn't understand them.

Of course, the Boycott-Novell folks have a very different view of things 
there.  But fortunately for me, I've been far enough away from that I've 
had no need to develop an informed opinion on it.  I very seldom have to 
deal with Office formatted docs of any kind (save for the usual .pps cute/
funny mail stuff making the rounds, and I just ignore that), I don't use 
Gnome for other reasons and haven't had to deal with mono, and Gentoo's 
sufficient for me so I've little interest in Novell/SuSE as a 
distribution.  So I've sufficiently few dealings with them or their 
controversial products that a boycott really isn't something that would 
affect either them or me.  The work of Greg KH (Novell employee, AFAIK) 
on the kernel is about as close as it gets, here, and evidently his 
integrity is sufficient I've seen nothing calling that into question.

-- 
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