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

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

-----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 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

-----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 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 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

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

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 Friday 19 November 2010, Stephen Shaw wrote:

On Fri, Nov 19, 2010 at 10:34, Pavol Rusnak 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 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, Nov 20, 2010 at 03:22:14PM +0100, Stefan Seyfried wrote:

On Sat, 20 Nov 2010 15:16:15 +0100 Petr Baudis 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

On Sat, 20 Nov 2010 15:16:15 +0100, Petr Baudis 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

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