Re: [gentoo-dev] Re: Downgrading glibc?
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 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Downgrading glibc?
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/
[gentoo-dev] Re: Downgrading glibc?
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?
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
[gentoo-dev] Re: 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/
Re: [gentoo-dev] Re: 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
Re: [gentoo-dev] Re: Downgrading glibc?
On Fri, Feb 11, 2011 at 1:27 PM, Diego Elio Pettenò flamee...@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?
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: Downgrading glibc?
On Fri, 11 Feb 2011 16:24:14 +0100 Diego Elio Pettenò flamee...@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.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
