[opensuse-factory] glibc plans for 11.4
Hi! My original plan has been to have glibc-2.13 in 11.4, however it is still completely unclear when will it be actually released. In case it is not soon enough, I would prefer to stay with glibc-2.11 in 11.4 instead of upgrading to glibc-2.12. Downsides are not terribly huge: - Missing these: * New interfaces: pthread_getname_np, pthread_setname_np * New Linux interface: recvmmsg * STT_GNU_IFUNC implemented for Sparc by David Miller. * The dynamic linker now recognizes supported ABI versions from the EI_ABIVERSION field in the ELF header. * New locales: kok_IN, sq_MK, cv_RU - Missing few more SSE string routine ifuncs. This can be also regarded as a plus since there are probably still some bugs lingering within, but it means SUSE won't be part of the testing process... Upsides: - 2.11 stable branch is getting a lot more bugfixes than 2.12 stable branch, therefore it should be less buggy and this gap will still widen over time - 2.11 is also better tested - Easier maintenance for me ;-) Does anyone have an opinion either way? And when would be the last suitable moment for glibc-2.13 entering Factory? Thanks, -- Petr "Pasky" Baudis The true meaning of life is to plant a tree under whose shade you will never sit. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Freitag 19 November 2010 schrieb Petr Baudis:
Does anyone have an opinion either way? The last glibc updates were kind of bumpy, so I'm very fine with leaving one out ;)
And when would be the last suitable moment for glibc-2.13 entering Factory?
This highly depends on what it will gain us - for a 10% performance gain on web browsing I'm sure users will accept some problems in RCs. But if it's "just" a version bump, it should be stable to enter past M5. I would even like to have a mass rebuild with the newer glibc, so this must be taking in too. So in dates: I would say friday, december 10th. Greetigns, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Nov 19, 2010 at 3:25 PM, Stephan Kulow <coolo@novell.com> wrote:
Am Freitag 19 November 2010 schrieb Petr Baudis:
Does anyone have an opinion either way? The last glibc updates were kind of bumpy, so I'm very fine with leaving one out ;)
And when would be the last suitable moment for glibc-2.13 entering Factory?
This highly depends on what it will gain us - for a 10% performance gain on web browsing I'm sure users will accept some problems in RCs. But if it's "just" a version bump, it should be stable to enter past M5. I would even like to have a mass rebuild with the newer glibc, so this must be taking in too. So in dates: I would say friday, december 10th.
Please make sure we are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=638477 . Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 19/11/10 13:36, İsmail Dönmez escribió:
Please make sure we are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
Thats a matter for adobe to fix, flash player is broken as usual. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Nov 19, 2010 at 6:41 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 19/11/10 13:36, İsmail Dönmez escribió:
Please make sure we are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
Thats a matter for adobe to fix, flash player is broken as usual.
Breaking flash player because glibc does some optimizations is unacceptable imho. Please read Linus' comments too. We shouldn't be breaking things that works. Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 19/11/10 13:46, İsmail Dönmez escribió:
Breaking flash player because glibc does some optimizations is unacceptable imho.
Having to use a permanently buggy propietary software since we have no alternative is what is unnaceptable. Please read Linus' comments too. We shouldn't be
breaking things that works.
what part of the manual isn't clear ? "The memcpy() function copies n bytes from memory area src to memory area dest. ***The memory areas should not overlap***. Use memmove(3) if the memory areas do overlap." it states clearly that the the memory areas should not overlap, and it has said so since several years. BTW.. apparently adobe will release a fix, because it is their code that is broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Nov 19, 2010 at 6:59 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 19/11/10 13:46, İsmail Dönmez escribió:
Breaking flash player because glibc does some optimizations is unacceptable imho.
Having to use a permanently buggy propietary software since we have no alternative is what is unnaceptable.
Please read Linus' comments too. We shouldn't be
breaking things that works.
what part of the manual isn't clear ?
Users don't care about programming manuals. You are just breaking stuff that works and that what they'll see: A broken flash player. Another solution is to patch Flash Player so that memcpy is replaced by memmove. I am not sure how legal is that though. Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/19/2010 12:01 PM, İsmail Dönmez wrote:
Hi;
On Fri, Nov 19, 2010 at 6:59 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 19/11/10 13:46, İsmail Dönmez escribió:
Breaking flash player because glibc does some optimizations is unacceptable imho.
Having to use a permanently buggy propietary software since we have no alternative is what is unnaceptable.
Please read Linus' comments too. We shouldn't be
breaking things that works.
what part of the manual isn't clear ?
Users don't care about programming manuals. You are just breaking stuff that works and that what they'll see: A broken flash player. Another solution is to patch Flash Player so that memcpy is replaced by memmove. I am not sure how legal is that though.
Patching is a no-no, but LD_PRELOAD could probably be used to override it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzms70ACgkQLPWxlyuTD7K1nQCff0ELC6eRKMPar+0r3TlPKk6R 6akAn13TLxgmUUDWJBgjzqBPJJQQmlJg =LmYU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Nov 19, 2010 at 7:28 PM, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2010 12:01 PM, İsmail Dönmez wrote:
Hi;
On Fri, Nov 19, 2010 at 6:59 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 19/11/10 13:46, İsmail Dönmez escribió:
Breaking flash player because glibc does some optimizations is unacceptable imho.
Having to use a permanently buggy propietary software since we have no alternative is what is unnaceptable.
Please read Linus' comments too. We shouldn't be
breaking things that works.
what part of the manual isn't clear ?
Users don't care about programming manuals. You are just breaking stuff that works and that what they'll see: A broken flash player. Another solution is to patch Flash Player so that memcpy is replaced by memmove. I am not sure how legal is that though.
Patching is a no-no, but LD_PRELOAD could probably be used to override it.
Hmmpf that means any browser using the plugin should LD_PRELOAD our memcpy.so, not a bad idea even if we only do it for Firefox/Chrome/Konqueror. Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/19/2010 12:31 PM, İsmail Dönmez wrote:
Hi;
On Fri, Nov 19, 2010 at 7:28 PM, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2010 12:01 PM, İsmail Dönmez wrote:
Hi;
On Fri, Nov 19, 2010 at 6:59 PM, Cristian Rodríguez <crrodriguez@opensuse.org> wrote:
El 19/11/10 13:46, İsmail Dönmez escribió:
Breaking flash player because glibc does some optimizations is unacceptable imho.
Having to use a permanently buggy propietary software since we have no alternative is what is unnaceptable.
Please read Linus' comments too. We shouldn't be
breaking things that works.
what part of the manual isn't clear ?
Users don't care about programming manuals. You are just breaking stuff that works and that what they'll see: A broken flash player. Another solution is to patch Flash Player so that memcpy is replaced by memmove. I am not sure how legal is that though.
Patching is a no-no, but LD_PRELOAD could probably be used to override it.
Hmmpf that means any browser using the plugin should LD_PRELOAD our memcpy.so, not a bad idea even if we only do it for Firefox/Chrome/Konqueror.
Not necessarily. You might not have the browser as a whole do it - you could have e.g. flashplayer wrapped in a script to do it. I haven't investigated all the the details as I'm not going to be the one doing the work - I just wanted to comment that the infrastructure is there to do it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzmtP4ACgkQLPWxlyuTD7KiaACeONjxnn9xurf+fKNm5LuAGOtp 9JYAn02QBQcsFVyTRED0wJc164imsDvR =ycGj -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Nov 19, 2010 at 7:33 PM, Jeff Mahoney <jeffm@suse.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 11/19/2010 12:31 PM, İsmail Dönmez wrote:
Hmmpf that means any browser using the plugin should LD_PRELOAD our memcpy.so, not a bad idea even if we only do it for Firefox/Chrome/Konqueror.
Not necessarily. You might not have the browser as a whole do it - you could have e.g. flashplayer wrapped in a script to do it.
I haven't investigated all the the details as I'm not going to be the one doing the work - I just wanted to comment that the infrastructure is there to do it.
Thats interesting, given that flash player is actually a shared object (libflashplayer.so) how can one make it preload another library? By using a third lib two load both in order? Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
El 19/11/10 14:31, İsmail Dönmez escribió:
Hmmpf that means any browser using the plugin should LD_PRELOAD our memcpy.so, not a bad idea even if we only do it for Firefox/Chrome/Konqueror.
No, is just a matter that Adobe releases an updated version of its software. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/19/2010 12:33 PM, Cristian Rodríguez wrote:
El 19/11/10 14:31, İsmail Dönmez escribió:
Hmmpf that means any browser using the plugin should LD_PRELOAD our memcpy.so, not a bad idea even if we only do it for Firefox/Chrome/Konqueror.
No, is just a matter that Adobe releases an updated version of its software.
I'm sure that will comfort the users who just say "opensuse broke flash, I'm going somewhere else" - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAkzmtTgACgkQLPWxlyuTD7KHKACfWBZNWyfpyFiYl4FeiTzQrzGf zuAAn1mAdYBmmXcFZeuqPJjYYBg5F7Wf =NNVA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 19/11/10 18:28, Jeff Mahoney wrote:
what part of the manual isn't clear ?
I am not a native speaker but "should not overlap" sounds like a recommendation to me. But please, let's not duplicate the flame from RHBZ also here. I hate Flash, but we should not ship broken software just because "Adobe is stupid".
Patching is a no-no, but LD_PRELOAD could probably be used to override it.
If you use LD_PRELOAD you will also affect the whole browser and make it slower. On 64bit we don't use Flash directly, so there we could just use LD_PRELOAD in nspluginwrapper. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o openSUSE Boosters Team Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9 prusnak[at]opensuse.org Czech Republic -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Fri, Nov 19, 2010 at 10:34, Pavol Rusnak <prusnak@opensuse.org> wrote:
On 19/11/10 18:28, Jeff Mahoney wrote:
what part of the manual isn't clear ?
I am not a native speaker but "should not overlap" sounds like a recommendation to me. But please, let's not duplicate the flame from RHBZ also here. I hate Flash, but we should not ship broken software just because "Adobe is stupid".
The last comment on the bug over at redhat is that adobe has fixed the bug and is currently testing it. This might be a completely mute point in a week or two, maybe a month? Cheers, Stephen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Friday 19 November 2010, Stephen Shaw wrote:
On Fri, Nov 19, 2010 at 10:34, Pavol Rusnak <prusnak@opensuse.org> wrote:
On 19/11/10 18:28, Jeff Mahoney wrote:
what part of the manual isn't clear ?
I am not a native speaker but "should not overlap" sounds like a recommendation to me.
Most standards have a policy of using MUST for requirements and SHOULD for recommendations, so yes
But please, let's not duplicate the flame from RHBZ also here. I hate Flash, but we should not ship broken software just because "Adobe is stupid".
The last comment on the bug over at redhat is that adobe has fixed the bug and is currently testing it. This might be a completely mute point in a week or two, maybe a month?
It may be moot, but it won't be mute unless we really do have the fix - it's going to be very very loud Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Fri, Nov 19, 2010 at 7:38 PM, Stephen Shaw <sshaw@decriptor.com> wrote:
On Fri, Nov 19, 2010 at 10:34, Pavol Rusnak <prusnak@opensuse.org> wrote:
On 19/11/10 18:28, Jeff Mahoney wrote:
what part of the manual isn't clear ?
I am not a native speaker but "should not overlap" sounds like a recommendation to me. But please, let's not duplicate the flame from RHBZ also here. I hate Flash, but we should not ship broken software just because "Adobe is stupid".
The last comment on the bug over at redhat is that adobe has fixed the bug and is currently testing it. This might be a completely mute point in a week or two, maybe a month?
I don't trust Adobe on release cycles, even critical security bugs takes weeks to be fixed. Regards, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi! On Fri, Nov 19, 2010 at 06:36:01PM +0200, İsmail Dönmez wrote:
Please make sure we are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
I'm aware of this bug. If the memcpy() backwards copy performance gain was significant, I'd be happy to argue about it, but for now, I'm far from convinced. Therefore, I'm inclined to disable this code for 11.4 - also because it can break other less wide-spread stuff we did not hear about yet, not just Flash. IMHO the proper way to do this would be to introduce new memcpy symbol version that can alias to non-memmove semantics and then we can expect newly compiled software to conform with and be tested with the proper semantics. However, this is most likely not going to happen given the glibc maintainers attitude. -- Petr "Pasky" Baudis The true meaning of life is to plant a tree under whose shade you will never sit. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 20 Nov 2010 15:16:15 +0100 Petr Baudis <pasky@suse.cz> wrote:
semantics. However, this is most likely not going to happen given the glibc maintainers attitude.
Maybe it is finally time to switch to eglibc. -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Nov 20, 2010 at 03:22:14PM +0100, Stefan Seyfried wrote:
On Sat, 20 Nov 2010 15:16:15 +0100 Petr Baudis <pasky@suse.cz> wrote:
semantics. However, this is most likely not going to happen given the glibc maintainers attitude.
Maybe it is finally time to switch to eglibc.
Which is only a psychological step, it does not really have much practical impact. I believe it is better to be as active within the upstream as possible than keep adding layers over the upstream. But it does require quite a thick skin and heaploads of patience. ABI issues are a reason why it is not really possible to do away with the current upstream and fork glibc as one could do with pretty much any other project. E.g. if the memcpy change I described above would not be done in the GNU glibc, that would instantly result in binary incompatibility total mayhem. -- Petr "Pasky" Baudis The true meaning of life is to plant a tree under whose shade you will never sit. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi; On Sat, Nov 20, 2010 at 4:16 PM, Petr Baudis <pasky@suse.cz> wrote:
On Fri, Nov 19, 2010 at 06:36:01PM +0200, İsmail Dönmez wrote:
Please make sure we are not affected by https://bugzilla.redhat.com/show_bug.cgi?id=638477 .
I'm aware of this bug. If the memcpy() backwards copy performance gain was significant, I'd be happy to argue about it, but for now, I'm far from convinced. Therefore, I'm inclined to disable this code for 11.4 - also because it can break other less wide-spread stuff we did not hear about yet, not just Flash.
Thats great to hear! Thanks, ismail -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 20 Nov 2010 15:16:15 +0100, Petr Baudis <pasky@suse.cz> wrote:
I'm aware of this bug. If the memcpy() backwards copy performance gain was significant,
Where do you draw the line? Some programmers also relied on undocumented behaviour or internal variables and cried murder when that changed. I remember times where some programmers assumed they could write to string constants.Or take the case of rpm segfaulting because it was linked statically but used one of the name resolution functions, i.e. those supplied by the libnss* libraries. Had that segfaulting binary been flashplayer or acrobat would you have changed glibc (which would only been possible by completely ripping out the nss stuff) or told the issuer to fix his application? Do you really believe the situation would have been different had the glibc folks warned the software world in advance that this would be coming? I've seen enough stupid programming bugs in open source applications to believe that binary only software isn't better but even worse. The question remains, where do we draw the line of acceptable wrong coding? Philipp -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
2010/11/20 Petr Baudis <pasky@suse.cz>:
I'm far from convinced. Therefore, I'm inclined to disable this code for 11.4 - also because it can break other less wide-spread stuff we did not hear about yet, not just Flash.
Supposing it is feasible... Patch memcpy to detect overlaps and abort() if they are detected. If bugzilla is taken down disable the backwards memcpy. Otherwise keep the patch so the problematic software is detected and finally disable the overlap detection in the release version. (advise from someone with a single computer that doesn't usually run Factory ;-) ) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi! On Fri, Nov 19, 2010 at 02:25:15PM +0100, Stephan Kulow wrote:
Am Freitag 19 November 2010 schrieb Petr Baudis:
Does anyone have an opinion either way? The last glibc updates were kind of bumpy, so I'm very fine with leaving one out ;)
And when would be the last suitable moment for glibc-2.13 entering Factory? This highly depends on what it will gain us - for a 10% performance gain on web browsing I'm sure users will accept some problems in RCs. But if it's "just" a version bump, it should be stable to enter past M5. I would even like to have a mass rebuild with the newer glibc, so this must be taking in too. So in dates: I would say friday, december 10th.
Okay, fair enough! :-) I will leave the glibc at 2.11 and do an update to 2.13 if it gets released in time. I'd say the chance is quite less than 50% now, but Ulrich Drepper seems to be even more unpredictable than usual now that he has left Redhat. :-( -- Petr "Pasky" Baudis The true meaning of life is to plant a tree under whose shade you will never sit. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (11)
-
Anders Johansson -
Cristian Morales Vega -
Cristian Rodríguez -
İsmail Dönmez -
Jeff Mahoney -
Pavol Rusnak -
Petr Baudis -
Philipp Thomas -
Stefan Seyfried -
Stephan Kulow -
Stephen Shaw