FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 02-11-2011, 11:06 AM
Sebastian Pipping
 
Default Downgrading glibc?

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
 
Old 02-11-2011, 11:20 AM
"Paweł Hajdan, Jr."
 
Default Downgrading glibc?

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.
 
Old 02-11-2011, 11:26 AM
"Paweł Hajdan, Jr."
 
Default Downgrading glibc?

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?
 
Old 02-11-2011, 11:27 AM
Diego Elio Pettenò
 
Default Downgrading glibc?

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/
 
Old 02-11-2011, 11:34 AM
Sebastian Pipping
 
Default Downgrading glibc?

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
 
Old 02-11-2011, 12:22 PM
Michael Haubenwallner
 
Default Downgrading glibc?

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
 
Old 02-11-2011, 12:23 PM
Michael Haubenwallner
 
Default Downgrading glibc?

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
 
Old 02-11-2011, 12:31 PM
Michiel de Bruijne
 
Default Downgrading glibc?

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.
 
Old 02-11-2011, 01:37 PM
Sebastian Pipping
 
Default Downgrading glibc?

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
 
Old 02-11-2011, 02:13 PM
Diego Elio Pettenò
 
Default Downgrading glibc?

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/
 

Thread Tools




All times are GMT. The time now is 11:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org