[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Michael Weber]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Um, what happend to the policy to not f*** around with stable ebuilds?

I see a violation of this rule at least on 2.13-r4, which leads to
useless rebuilds on `emerge -avuND world` on every single gentoo
install world-wide.

Please don't do that.

  Michael


On 01/18/2012 12:51 AM, Mike Frysinger (vapier) wrote:
> vapier      12/01/17 23:51:59
> 
> Modified:             glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild 
> glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild
> glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild
> ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild 
> glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild
> glibc-2.14.1.ebuild Log: Drop gettext dep (cannot think of a reason
> for it), and drop USE=nls since the --disable-nls flag has not been
> in the glibc source for quite some time #398981 by Maxim Kammerer.
> 
> (Portage version: 2.2.0_alpha84/cvs/Linux x86_64)
> 

- -- 
- --
Gentoo Dev
http://xmw.de/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk8XgwYACgkQknrdDGLu8JAbiQD+M20dckc2qYzAb9Qakx07Qc/Z
fdx6br/11ZYqCb4lR1YA/1So5PZYmn5hVaIr5qAqho/MjUlzEZxDxy2gz2Vy2OsF
=vmQ3
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 474 bytes --]

On Wednesday 18 January 2012 21:42:14 Michael Weber wrote:
> Um, what happend to the policy to not f*** around with stable ebuilds?

take a chill pill phil

> I see a violation of this rule at least on 2.13-r4, which leads to
> useless rebuilds on `emerge -avuND world` on every single gentoo
> install world-wide.

i don't have too much compassion for -N.  if people really care enough about 
it, they'd read the ChangeLog and see that it is meaningless.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Duncan]

Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted:

> On Wednesday 18 January 2012 21:42:14 Michael Weber wrote:
>> Um, what happend to the policy to not f*** around with stable ebuilds?
> 
> take a chill pill phil
> 
>> I see a violation of this rule at least on [glibc-]2.13-r4, which
>> leads to useless rebuilds on `emerge -avuND world` on every single
>> gentoo install world-wide.
> 
> i don't have too much compassion for -N.  if people really care enough
> about it, they'd read the ChangeLog and see that it is meaningless.

Considering glibc was just one of some 200-ish packages I rebuilt early 
today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which 
will be in-overlay for just a few more days as 4.8-release is due next 
week, because gentoo/kde just removed the long-masked kdeenablefinal USE 
flag, which because it was masked (and I didn't unmask it) did NOT affect 
my kde as installed so I basically did the rebuild for nothing...

I'm not going to complain much about a mere single package, glibc, 
triggering a -N rebuild.

But I'm not going to complain about gentoo/kde doing it with 200-ish, 
either (way more if I had all of kde installed, I don't), for several 
reasons:

1) I'm not only running ~arch, I'm running the overlay.

2) I'm not only running the overlay, I'm deliberately unmasking and 
running upstream prereleases.

But more important than either of those...

3) Mike's right.  The -N is simply available to give users a way to be 
notified of such changes if they wish to be, presumably thru use of -p or 
-a.  It DOESN'T mean they have to actually do the remerge, as they can 
either choose to ignore -N and not use it entirely, thus remaining 
blissfully unaware of such changes, or use it simply as notification, go 
look at the logs and see what the change was about, and decide based on 
that whether it's worth the remerge.

I simply chose to do the 200+ package rebuild because I've learned that 
once I use -N to find out and investigate (which I do), after making any 
appropriate changes on my end, with a quad-core system, enough RAM to 
point PORTAGE_TMPDIR at tmpfs, and PORTAGE_NICENESS set to 19, it's 
simply easier to do the rebuild and not worry about it any more than it 
is to have to continue to mentally negate those changes every time I do 
the -N checks until I DO either rebuild or update.

Plus, I look at it this way. It's winter here in Phoenix and while 
Phoenix isn't too cold, it was cold enough last nite that the extra 
computer heat from rebuilding a couple hundred packages didn't go to 
waste! =:^)  If it were summer and I was having to run the AC to pump 
that heat outside, too, my decision may well have been different, 
especially since I'll already be updating to the full release when it 
comes out in a week or so.  But then again maybe not, too, because I 
simply rest better when I know I'm all updated and my computer's all 
squared away with gentoo and the various overlays I follow. But either 
way, it's my decision, and I appreciate that Gentoo respects that and 
leaves the decision to me. =:^)

That said, I also appreciate the care big projects like gentoo/kde 
normally take to synchronize such big changes to release, keywording and 
stabilization updates, as /either/ doing 200+ unnecessary rebuilds very 
often, or conversely, the constant tension of knowing I'm not fully 
synced if I continuously ignored -N packages, would get old rather fast.

But for a single package, meh...

-- 
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-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Dale]

Duncan wrote:
> Considering glibc was just one of some 200-ish packages I rebuilt early
> today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which
> will be in-overlay for just a few more days as 4.8-release is due next
> week, because gentoo/kde just removed the long-masked kdeenablefinal USE
> flag, which because it was masked (and I didn't unmask it) did NOT affect
> my kde as installed so I basically did the rebuild for nothing...
>
> I'm not going to complain much about a mere single package, glibc,
> triggering a -N rebuild.
>
> But I'm not going to complain about gentoo/kde doing it with 200-ish,
> either (way more if I had all of kde installed, I don't), for several
> reasons:
>
> 1) I'm not only running ~arch, I'm running the overlay.
>
> 2) I'm not only running the overlay, I'm deliberately unmasking and
> running upstream prereleases.
>
> But more important than either of those...
>
> 3) Mike's right.  The -N is simply available to give users a way to be
> notified of such changes if they wish to be, presumably thru use of -p or
> -a.  It DOESN'T mean they have to actually do the remerge, as they can
> either choose to ignore -N and not use it entirely, thus remaining
> blissfully unaware of such changes, or use it simply as notification, go
> look at the logs and see what the change was about, and decide based on
> that whether it's worth the remerge.
>
> I simply chose to do the 200+ package rebuild because I've learned that
> once I use -N to find out and investigate (which I do), after making any
> appropriate changes on my end, with a quad-core system, enough RAM to
> point PORTAGE_TMPDIR at tmpfs, and PORTAGE_NICENESS set to 19, it's
> simply easier to do the rebuild and not worry about it any more than it
> is to have to continue to mentally negate those changes every time I do
> the -N checks until I DO either rebuild or update.
>
> Plus, I look at it this way. It's winter here in Phoenix and while
> Phoenix isn't too cold, it was cold enough last nite that the extra
> computer heat from rebuilding a couple hundred packages didn't go to
> waste! =:^)  If it were summer and I was having to run the AC to pump
> that heat outside, too, my decision may well have been different,
> especially since I'll already be updating to the full release when it
> comes out in a week or so.  But then again maybe not, too, because I
> simply rest better when I know I'm all updated and my computer's all
> squared away with gentoo and the various overlays I follow. But either
> way, it's my decision, and I appreciate that Gentoo respects that and
> leaves the decision to me. =:^)
>
> That said, I also appreciate the care big projects like gentoo/kde
> normally take to synchronize such big changes to release, keywording and
> stabilization updates, as /either/ doing 200+ unnecessary rebuilds very
> often, or conversely, the constant tension of knowing I'm not fully
> synced if I continuously ignored -N packages, would get old rather fast.
>
> But for a single package, meh...
>

I do a little overkill when I do my updates.  I run emerge -uvaDN world 
and let it do its thing.  I would rather rebuild a package or two, or 
possibly even more, and know for sure that my system is more sane than I 
am.  I started doing it this way because I was running into issues with 
packages being upgraded and another kinda sort of needing it but not to 
the point that it poked portage in the eye.

That said, if I start having the same issue with emerge -uvaDN world, 
I'll be doing emerge -ev world then, just to make sure it catches it 
all.  I may not do that as often but at least it gives me the system 
stability I want.

I do have one wish.  I wish some changes were planned a little better.  
Things like KDE, LOo and a maybe a couple other large packages, get some 
change then just a few days latter, another change that requires a 
recompile.  I do wish sometimes that both changes could be done at the 
same time.  I'm not complaining mind you.  It's just a wish.

I'm with Duncan tho.  It's cold right now.  I can't get folding to 
download a unit and I need some HEAT.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Wed, 18 Jan 2012 22:00:52 -0500
Mike Frysinger <vapier@gentoo.org> wrote:

> > I see a violation of this rule at least on 2.13-r4, which leads to
> > useless rebuilds on `emerge -avuND world` on every single gentoo
> > install world-wide.
> 
> i don't have too much compassion for -N.  if people really care
> enough about it, they'd read the ChangeLog and see that it is
> meaningless. -mike

I wonder why locale-gen stopped working after a meaningless rebuild.
But that's probably my fault somehow. Bad moon phase or something.

 *  (1/3) Generating pl_PL.UTF-8 ...locale alias file
   `/usr/share/locale/locale.alias' not found: No such file or
   directory [ !! ]

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 855 bytes --]

On Thursday 19 January 2012 04:32:01 Michał Górny wrote:
> On Wed, 18 Jan 2012 22:00:52 -0500 Mike Frysinger wrote:
> > > I see a violation of this rule at least on 2.13-r4, which leads to
> > > useless rebuilds on `emerge -avuND world` on every single gentoo
> > > install world-wide.
> > 
> > i don't have too much compassion for -N.  if people really care
> > enough about it, they'd read the ChangeLog and see that it is
> > meaningless.
> 
> I wonder why locale-gen stopped working after a meaningless rebuild.
> But that's probably my fault somehow. Bad moon phase or something.
> 
>  *  (1/3) Generating pl_PL.UTF-8 ...locale alias file
>    `/usr/share/locale/locale.alias' not found: No such file or
>    directory [ !! ]

pretty sure /usr/share/locale/locale.alias has always been unconditionally 
installed by glibc
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 301 bytes --]

On Thu, 19 Jan 2012 03:42:14 +0100
Michael Weber <xmw@gentoo.org> wrote:

> Um, what happend to the policy to not f*** around with stable ebuilds?

I don't think such a rule has any meaning considering that those
ebuilds are mostly contained in an eclass.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild glibc-2.14.ebuild glibc-2.13-r2.ebuild ChangeLog glibc-2.13-r4.ebuild glibc-2.11.3.ebuild glibc-2.9_p20081201-r3.ebuild glibc-2.12.1-r3.ebuild glibc-2.14.1.ebuild

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 526 bytes --]

On Thursday 19 January 2012 04:32:46 Michał Górny wrote:
> On Thu, 19 Jan 2012 03:42:14 +0100 Michael Weber wrote:
> > Um, what happend to the policy to not f*** around with stable ebuilds?
> 
> I don't think such a rule has any meaning considering that those
> ebuilds are mostly contained in an eclass.

pedantically speaking, i think you're thinking of gcc.  glibc is mostly 
contained in eblits.  practically speaking, it's mostly the same, although 
there's a bit more control over things with eblits.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]