[gentoo-dev] Downgrading glibc?

[gentoo-dev] Downgrading glibc?

[Sebastian Pipping]

Hello!


In relation to bug 354395 [1] I would like to downgrade my glibc back to
2.12.2.  Portage doesn't allow me to do that:

 * Sanity check to keep you from breaking your system:
 *  Downgrading glibc is not supported and a sure way to destruction
 * ERROR: sys-libs/glibc-2.12.2 failed (setup phase):
 *   aborting to save your system

Can anyone guide me or point me to a guide how to savely do that manually?

Thanks,



Sebastian


[1] https://bugs.gentoo.org/show_bug.cgi?id=354395

[gentoo-dev] Re: Downgrading glibc?

[Diego Elio Pettenò]

Il giorno ven, 11/02/2011 alle 09.50 +0100, Sebastian Pipping ha
scritto:
> 
> 
> Can anyone guide me or point me to a guide how to savely do that
> manually? 

There really isn't a safe way as soon as you built anything at all
against the new version.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Downgrading glibc?

[Michael Haubenwallner]

On 02/11/2011 09:50 AM, Sebastian Pipping wrote:
> In relation to bug 354395 [1] I would like to downgrade my glibc back to
> 2.12.2.  Portage doesn't allow me to do that:
> 
>  * Sanity check to keep you from breaking your system:
>  *  Downgrading glibc is not supported and a sure way to destruction
>  * ERROR: sys-libs/glibc-2.12.2 failed (setup phase):
>  *   aborting to save your system
> 
> Can anyone guide me or point me to a guide how to savely do that manually?

While it actually would be interesting to see some downgrade path even for glibc,

> [1] https://bugs.gentoo.org/show_bug.cgi?id=354395

what do you think of working around the memcpy troubles with glibc-2.13 by
simply redirecting memcpy to memmove within glibc, either unconditionally or
optional/temporary (via USE-flag?) until everyone uses memmove where necessary?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

[gentoo-dev] Re: Downgrading glibc?

[Diego Elio Pettenò]

Il giorno ven, 11/02/2011 alle 10.55 +0100, Michael Haubenwallner ha
scritto:
> 
> what do you think of working around the memcpy troubles with
> glibc-2.13 by
> simply redirecting memcpy to memmove within glibc, either
> unconditionally or
> optional/temporary (via USE-flag?) until everyone uses memmove where
> necessary?

That unless things start crashing down nobody will fix the issues at
all.

We're not talking a last minute change! memcpy() *always* documented not
to use overlapping memory areas.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

[gentoo-dev] Re: Downgrading glibc?

[Duncan]

Diego Elio Pettenò posted on Fri, 11 Feb 2011 10:22:44 +0100 as excerpted:

> Il giorno ven, 11/02/2011 alle 09.50 +0100, Sebastian Pipping ha
> scritto:
>> 
>> 
>> Can anyone guide me or point me to a guide how to savely do that
>> manually?
> 
> There really isn't a safe way as soon as you built anything at all
> against the new version.

The glibc ebuild really needs an override, like the usual check for 
I_KNOW_WHAT_I_AM_DOING_AND_WILL_KEEP_THE_PIECES_IF_IT_BREAKS or some such, 
set in the environment.  Failing to have such an override at all, seems 
rather unGentooish to me.

Fortunately for me (I haven't upgraded to 2.13 yet, but ran into the need 
to downgrade an ~arch version myself not long ago, I hadn't emerged 
anything of major interest since so the warning was incorrect on its 
face), Gentoo has a number of alternative methods to enforce one's will 
over an obstinate system, if one believes it necessary.  I think I copied 
to my personal overlay and edited the ebuild there... after cursing the 
fact that I couldn't simply set some sort of var to get the perfectly good 
binpkg of the old version to install.  The problem has since been fixed 
and I've upgraded past it, since.

If that hadn't worked, I'd have tried the untar-the-binpkg-over-the-live-fs 
thing.  Either that, or the boot to backup snapshot, set ROOT 
appropriately, and emerge from there.

-- 
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] Downgrading glibc?

[Sebastian Pipping]

A little update from my side:


I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now
gone again!  If it's not glibc itself, it's one of the packages
re-installed after (again, see [1] for the list).

If anyone considers masking glibc 2.13 for now: please take my vote.

Best,



Sebastian


[1] https://bugs.gentoo.org/show_bug.cgi?id=354395

Re: [gentoo-dev] Downgrading glibc?

["Paweł Hajdan, Jr."]

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

On 2/11/11 10:55 AM, Michael Haubenwallner wrote:
> what do you think of working around the memcpy troubles with glibc-2.13 by
> simply redirecting memcpy to memmove within glibc, either unconditionally or
> optional/temporary (via USE-flag?) until everyone uses memmove where necessary?

I'm not a maintainer of base-system, but it seems to me that such a
change in behavior would only add to the confusion. glibc behaving
differently on Gentoo than other distros... no, that doesn't sound good.

Paweł Hajdan, Jr.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

Re: [gentoo-dev] Downgrading glibc?

["Paweł Hajdan, Jr."]

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

On 2/11/11 1:06 PM, Sebastian Pipping wrote:
> I was abe to downgrade glibc to 2.12.2 and my sound problem [1] is now
> gone again!

Just curious, what downgrade method did you use? Just untaring an older
glibc package?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 194 bytes --]

[gentoo-dev] Re: Downgrading glibc?

[Diego Elio Pettenò]

Il giorno ven, 11/02/2011 alle 13.06 +0100, Sebastian Pipping ha
scritto:
> 
> If anyone considers masking glibc 2.13 for now: please take my vote.

It should have been masked _beforehand_, masking it now is going to
cause more trouble.

Remember: unless you're able to rebuild everything that was built
afterwards without _using_ it, your system is going to be totally
broken.

Sure it sucks, haven't I said that enough times, regarding pushing stuff
that's going to break other stuff straight to ~arch?

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Downgrading glibc?

[Sebastian Pipping]

On 02/11/11 13:26, "Paweł Hajdan, Jr." wrote:
> Just curious, what downgrade method did you use? Just untaring an older
> glibc package?

This is what I did:

 0) Log out of X, log in to root console

 1) Collect packages emerged after previous update to glibc from
    files in PORT_LOGDIR (using simple shell scripting)

 2) Emerge glibc 2.12.2

 3) Re-emerge packages from (1)

 4) Reboot

WARNING: It may not work as well on your system.

Best,



Sebastian

Re: [gentoo-dev] Downgrading glibc?

[Michael Haubenwallner]

On 02/11/2011 01:20 PM, "Paweł Hajdan, Jr." wrote:
> On 2/11/11 10:55 AM, Michael Haubenwallner wrote:
>> what do you think of working around the memcpy troubles with glibc-2.13 by
>> simply redirecting memcpy to memmove within glibc, either unconditionally or
>> optional/temporary (via USE-flag?) until everyone uses memmove where necessary?
> 
> I'm not a maintainer of base-system, but it seems to me that such a
> change in behavior would only add to the confusion. glibc behaving
> differently on Gentoo than other distros... no, that doesn't sound good.

While Fedora 14 has shipped with glibc-2.13 and vanilla memcpy it seems, I'm really
curious if a next Red Hat Enterprise Linux or any distribution designed for enterprise
environments would do so, risking commercial applications to break.

So I'm not convinced yet that they can perpetuate this new memcpy implementation.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Downgrading glibc?

[Michael Haubenwallner]

On 02/11/2011 11:12 AM, Diego Elio Pettenò wrote:
> Il giorno ven, 11/02/2011 alle 10.55 +0100, Michael Haubenwallner ha
> scritto:
>>
>> what do you think of working around the memcpy troubles with
>> glibc-2.13 by
>> simply redirecting memcpy to memmove within glibc, either
>> unconditionally or
>> optional/temporary (via USE-flag?) until everyone uses memmove where
>> necessary?
> 
> That unless things start crashing down nobody will fix the issues at
> all.
> 
> We're not talking a last minute change! memcpy() *always* documented not
> to use overlapping memory areas.

Yes, *documented*, I'm aware of that.

But both that document as well as uncountable lines of source code are rather old.
While the source code isn't that large a problem for Gentoo, existing binaries
without source code still are.

The questions simply are:
*) Does anyone really need memcpy when there is memmove?
*) Is it worth the effort to bug everyone to replace memcpy by memmove in their
   existing applications, with or without investigating that memcpy doesn't suffice?

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Downgrading glibc?

[Michiel de Bruijne]

On Fri, Feb 11, 2011 at 1:27 PM, Diego Elio Pettenò <flameeyes@gmail.com> wrote:
>
> Il giorno ven, 11/02/2011 alle 13.06 +0100, Sebastian Pipping ha
> scritto:
> >
> > If anyone considers masking glibc 2.13 for now: please take my vote.
>
> It should have been masked _beforehand_, masking it now is going to
> cause more trouble.
>

Given this situation; it is desirable for future Portage/EAPI to be
able to create a deptree depending on whether an atom is already
installed or not?

With this functionality it is possible to "mask" a
package-without-downgrade-path again for systems that haven't the new
atom installed yet.

It should be used as little as possible of course, but for situations
like this the damage can be limited to as few systems as possible.

Re: [gentoo-dev] Re: Downgrading glibc?

[Sebastian Pipping]

On 02/11/2011 01:27 PM, Diego Elio Pettenò wrote:
> It should have been masked _beforehand_, masking it now is going to
> cause more trouble.

Portage will propose a downgrade of glibc on emerge-update-world, okay.
How bad would that be?  Does it cause any other trouble?


> Remember: unless you're able to rebuild everything that was built
> afterwards without _using_ it, your system is going to be totally
> broken.
> 
> Sure it sucks, haven't I said that enough times, regarding pushing stuff
> that's going to break other stuff straight to ~arch?

In your eyes, is there anything we can do to improve the current situation?

Best,



Sebastian

[gentoo-dev] Re: Re: Downgrading glibc?

[Diego Elio Pettenò]

Il giorno ven, 11/02/2011 alle 15.37 +0100, Sebastian Pipping ha
scritto:
> Portage will propose a downgrade of glibc on emerge-update-world, okay.
> How bad would that be?  Does it cause any other trouble?

And glibc will refuse to downgrade unless you hack the ebuild. Now let's
say that the user rebuilt gcc after the glibc upgrade, and now forces
downgrade; after forcing downgrade, gcc will fail to find the symbols
with higher versioning (GNU versioning), which means it won't run.

> In your eyes, is there anything we can do to improve the current situation?

Every time a base package changes that could cause huge breakage, mask,
send a message to qa@gentoo.org to start up testing ebuild $foo with an
unmask list, and wait till we give the go before unmasking.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

[gentoo-dev] Re: Re: Downgrading glibc?

[Diego Elio Pettenò]

Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha
scritto:
> 
> But both that document as well as uncountable lines of source code are
> rather old.
> While the source code isn't that large a problem for Gentoo, existing
> binaries
> without source code still are.

Beside flash what else is involved for now? We can decide that once
that's defined.

-- 
Diego Elio Pettenò — Flameeyes
http://blog.flameeyes.eu/

Re: [gentoo-dev] Re: Re: Downgrading glibc?

[Samuli Suominen]

On 02/11/2011 05:13 PM, Diego Elio Pettenò wrote:
> Il giorno ven, 11/02/2011 alle 15.37 +0100, Sebastian Pipping ha
> scritto:
>> Portage will propose a downgrade of glibc on emerge-update-world, okay.
>> How bad would that be?  Does it cause any other trouble?
> 
> And glibc will refuse to downgrade unless you hack the ebuild. Now let's
> say that the user rebuilt gcc after the glibc upgrade, and now forces
> downgrade; after forcing downgrade, gcc will fail to find the symbols
> with higher versioning (GNU versioning), which means it won't run.
> 
>> In your eyes, is there anything we can do to improve the current situation?
> 
> Every time a base package changes that could cause huge breakage, mask,
> send a message to qa@gentoo.org to start up testing ebuild $foo with an
> unmask list, and wait till we give the go before unmasking.
> 

That will be definately done for libpng-1.5.1 that just hit tree with
KEYWORDS="".

It turns most, if not all deprecation warnings from libpng-1.4.x series
to fatal errors.

ABI break, .la files drop and the fun of 90% of packages not building
against it \o/

- Samuli

[gentoo-dev] Re: Downgrading glibc?

[Ryan Hill]

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

On Fri, 11 Feb 2011 16:24:14 +0100
Diego Elio Pettenò <flameeyes@gmail.com> wrote:

> Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha
> scritto:
> > 
> > But both that document as well as uncountable lines of source code are
> > rather old.
> > While the source code isn't that large a problem for Gentoo, existing
> > binaries
> > without source code still are.
> 
> Beside flash what else is involved for now? We can decide that once
> that's defined.

There's a patch for flash.  Skype is broken.
Tracker: https://bugs.gentoo.org/353816


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

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

Re: [gentoo-dev] Re: Downgrading glibc?

[Mike Frysinger]

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

On Saturday, February 12, 2011 00:37:12 Ryan Hill wrote:
> Tracker: https://bugs.gentoo.org/353816

typo; you meant:
https://bugs.gentoo.org/354107
-mike

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

Re: [gentoo-dev] Re: Re: Downgrading glibc?

[Michael Haubenwallner]

On 02/11/11 16:24, Diego Elio Pettenò wrote:
> Il giorno ven, 11/02/2011 alle 14.23 +0100, Michael Haubenwallner ha
> scritto:
>>
>> But both that document as well as uncountable lines of source code are
>> rather old.
>> While the source code isn't that large a problem for Gentoo, existing
>> binaries
>> without source code still are.
> 
> Beside flash what else is involved for now? We can decide that once
> that's defined.

I've heard a colleague of mine debugged for 50(!) hours after moving some
quite old application to some recent Linux before he replaced a memcpy by
memmove, so this did ring some bells.

However, now he said this was on Ubuntu 10.04.1 LTS, having glibc-2.11,
so this might have been unrelated indeed.

Anyway, running old applications on recent Linux is quite common in
"enterprise" world (where Gentoo might not be such a big player).

So I'm fine with Gentoo shipping vanilla memcpy, I'm just curious
if next RHEL will do.

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

Re: [gentoo-dev] Re: Re: Downgrading glibc?

[Stanislav Ochotnicky]

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

On 02/16/2011 11:06 AM, Michael Haubenwallner wrote:
> So I'm fine with Gentoo shipping vanilla memcpy, I'm just curious
> if next RHEL will do.

I'd be surprised as hell to find out Red Hat changed this in current
RHELs (5 and 6) during their lifetime. On the other hand I'd be equally
surprised if Red Hat wouldn't use upstream implementation in future
products. If Fedora is any example, they will keep upstream
implementation. Also RHEL 6 is still pretty fresh, so there are quite a
few years until RHEL 6.0 goes EOL so software vendors have time to fix
their problems :-)

-- 
Stanislav Ochotnicky

PGP: 7B087241
jabber: stanislav@ochotnicky.com


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Re: Re: Downgrading glibc?

[James Cloos]

>>>>> "MH" == Michael Haubenwallner <haubi@gentoo.org> writes:

MH> I've heard a colleague of mine debugged for 50(!) hours after moving
MH> some quite old application to some recent Linux before he replaced a
MH> memcpy by memmove, so this did ring some bells.

MH> However, now he said this was on Ubuntu 10.04.1 LTS, having
MH> glibc-2.11, so this might have been unrelated indeed.

Check the archives of the glibc lists, as well as its bug db.

There has been quite a bit of discussion there on that issue.

It was added for sse3 some time ago; I beleive it was Intel engineers
who contributed it for sse3, showing that it was inedeed faster on their
chips to start at the high point and decrement the counter rather than
starting at the low point and incrementing.

The discussion in their lists does a better job of documenting the issue.

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6