Akemi Yagi wrote:

On Wed, Aug 27, 2008 at 5:59 PM, John Summerfield debian@herakles.homelinux.org wrote:

...

Akemi Yagi wrote:

...

( questions, since I dont use perl myself )

Try removing it. I think you will find you do:-) There's rather a lot of packages depend on it including. KDE, spamasassin, mysql, emacs, rpm-build, gnome (I think), xorg, postfix, java, ghostscript and squid.

I do use perl :-) The portion you quoted above is part of Karanbir's message. Of course we all know what he meant by that statement...

yes, I pruned a little aggressively. yes, he implies it doesn't matter to him. My point is it probably matters to him more than he realises:-)

In my reading up on the topic, I found someone mentioned that it would be good to have a benchmark. Someone else poopooed the idea. I'd like to support the idea of a kind of benchmark.

A while back, I worked on some IBM software, including its PL/I compiler. One of my tasks was to run some testcases. Some of these testcases dated back around thirty years! Mostly, they were to ensure conformance to some documented standards and to verify bugs fixed before were still fixed. As you might expect on reflection, sometimes a failure was a success (the program was expected to fail), and often the output varied from one run to another (eg time/date on listings).

Unexpected results had to be examined, explained and maybe fixed.

Running such a test suite on PERL makes sense (and is probably done). One of the outcomes that needs to be measured and explained is the time (and other resources) it takes to run the tests, and how it compares with expectations. In this case, measuring the time and resources would/should have identified the problem.

Arguably, this should be done/monitored by Red Hat.

On Sat, 2008-08-30 at 00:02 +0200, Dag Wieers wrote:

On Wed, 27 Aug 2008, Karanbir Singh wrote:

...

...

should explore the problem further with TUV and the CentOS community. If a fix is not forthcoming from TUV, I reluctantly suggest that we get together with the CentOS people and fork this portion of the distro, perhaps standardizing on Perl 5.10 . There are people in the Perl community ready to assist us.

While forking the whole perl subsection of the distro is a bit drastic, I am quite happy to have a perl in C5Plus. Does someone want to get in touch with Keith and get a summary on what needs fixing in this case ? Also - if the conversation was to take place on centos-devel list, would be much cooler.

Upstream have said the fix will be in 5U3, and considering that might be still a few months away, could we get something sorted before then ?

To be honest, if this problem was part of RHEL5 since its inception and only a few people until now have actually been bugged by it. I don't see a good reason to release something now only because someone was able to make a big poo out of it and got to slashdot.

We do not want to give attention-seekers more airtime, before we know it everyone who finds a bug starts shouting.

(Don't read me wrong, of course it should be fixed, I am just concerned about the motives and the generality of this bug wrt. other bugs.)

+1 My 2cents: Build a package using the patches from the f8 package. Test it for the change in speed. Put it up somewhere people can get to it easily and post a note in the centos bug report on it and on the rh bugzilla report where the centos build is that fixes the problem.

that's it.

the people who care can fix their problem until there's a final upstream fix and you don't give any more airtime to the people yelling about it.

-sv

Karanbir Singh wrote:

Seth Vidal wrote:

...

...

(Don't read me wrong, of course it should be fixed, I am just concerned about the motives and the generality of this bug wrt. other bugs.)

+1 Build a package using the patches from the f8 package. Test it for the change in speed. Put it up somewhere people can get to it easily and post a note in the centos bug report on it and on the rh bugzilla report where the centos build is that fixes the problem.

That is exactly how I feel as well. and is what I am hoping to achieve.

There is now a perl package in the c5-testing repo that fix's these issues. Unless I hear reports of breakage in the next 24 hrs, will push that out via the fasttrack repo and make some announcements.

Also, if you do test it - and it does work fine : let us know about that too.

Regards,

- KB

On Sun, 2008-08-31 at 09:01 -0400, William L. Maltby wrote:

<snip>

I'll run throughout the day (rebooting for a clean start right ofter this post) and report either NPs seen or anything I notice.

I've not detected any issues in my use. From my POV, it's GTG (Good To Go).

...

Regards,

• KB

On Sun, 2008-08-31 at 15:09 +0200, Fabian Arrotin wrote:

<snip>

I've just updated a tmp DomU machine : Without the updated perl : time /tmp/perlbug.pl .................................................. real 0m21.473s user 0m21.345s sys 0m0.044s

with perl.x86_64 4:5.8.8-10.el5_2.3.centos from Testing : time /tmp/perlbug.pl .................................................. real 0m0.214s user 0m0.188s sys 0m0.024s

The test was run several times with approximatively the same results (and after a reboot too) The perl script used was the one someone posted on the CentOS list recently :

------------- bug test ---------- #!/usr/bin/perl use overload q(<) => sub {}; my %h; for (my $i=0; $i<50000; $i++) { $h{$i} = bless [ ] => 'main'; print STDERR '.' if $i % 1000 == 0; } ----------------- end snip ------------

I'll test on other machines but i admit i'm not a Perl user myself nor have perl scripts that i use for day-to-day operations

I ran that on mine and have similar good results. I'd forgotten about the test script someone posted.

On an AMD Athlon XP3200+ (2200.080 MHz, 4403.11 BogoMIPS) I got similar to this.

real 0m0.286s user 0m0.234s sys 0m0.018s

Thanks.

David Hrbáč wrote:

if we have axiom, I believe it's still valid, that we are lim 100 pct binary compatible with upstream, patched perl package should be pushed out via centosplus.

Thats a good point. however, couple of things to consider here:

- were not pushing perl to everyone by putting it in fasttrack, people need to opt into that repo manually.

- This is essentially a bugfix, with low enough Release tag that the next update from upstream will be > EVR

- There is strong indication from upstream that they will push a version of perl into 5.2, either as an update or into fastrack; and this is likely to happen soon.

- Putting these perl packages into centosplus also raises the issue of how we would maintain perl in centosplus for the rest of the life of centos4/5 ; And I dont really see enough reason to maintain perl there.

The other, very real, option is to say : lets leave them in the -Testing repo and just create enough info at the right places ( bugzilla.r.c bugs.c.o, blog posts etc ) - on how users might get the packages from the Testing repo. My pref is still to push via fasttrack though, given the nature of the other packages that are also in the Testing repo.

Hi Marcus,

Marcus Moeller wrote:

...

• were not pushing perl to everyone by putting it in fasttrack, people

need to opt into that repo manually.

I guess this is the first time where CentOS fasttrack is faster then RH's. I agree with David that even ft should not differ from upstream in that way.

well, the thing is - on CentOS-5, the fasttrack repo isnt the same as upstream anyway. And no this wont be the first time there is a centos fix public before rh's either.

- KB

David Hrbác wrote:

how come? What's the difference between C5 and C4 fasttrack repo? I don't remember having any announcement.

The C4 fasttrack repo is built in sync with upstream, there is no fasttrack on C5 ( go look at mirror.centos.org ).

- KB

On Mon, 1 Sep 2008, David Hrbác( wrote:

Karanbir Singh napsal(a):

...

The C4 fasttrack repo is built in sync with upstream, there is no fasttrack on C5 ( go look at mirror.centos.org ).

• KB

I know, C5 is empty for now. I expect to have fast(t)rack only RPMs here.

Me too. I think a 'centosfix' repository with lower release numbers than the expected RH fix may be useful. Calling it centosfix also makes it obvious these are centos packages, and not RH rebuild packages.

This 'centosfix' concept could be stretched to fix some other packages with known problems until upstream gets them fixed. And is a deliberate opt-in from users that need them (and understand the risks).

If there is a market for the slow-perl fix, and more of these packages would see the light of day, I would prefer a 'centosfix' repository over a mixed fast(t)rack repository. But only if we can deliver...

On Tue, 2008-09-02 at 08:12 +0800, John Summerfield wrote:

A first-run option to enable these repos (and maybe a system-config[1] tool to reconfigure available repos) would highlight the fact that these repos exist.

pirut can already do that, as can PK (as a stand alone tool, although it requires the PK backend).

[1] or maybe yum could be extended to list and change the state of repos.

yum repolist all, does this, in 3.2.8

On Wed, 3 Sep 2008, John Summerfield wrote:

James Antill wrote:

...

pirut can already do that, as can PK (as a stand alone tool, although it requires the PK backend).

pirut isn't useful without graphics, and I don't ordinarily use graphics on machines I administer remotely.

I don't know what PK is.

Fedora or bleeding edge leakage, I think ... perhaps PackageKit <?>

-- Russ herrold

On Mon, 1 Sep 2008, Karanbir Singh wrote:

David Hrbác wrote:

...

how come? What's the difference between C5 and C4 fasttrack repo? I don't remember having any announcement.

The C4 fasttrack repo is built in sync with upstream, there is no fasttrack on C5 ( go look at mirror.centos.org ).

Karanbir,

Is there a reason why there is no fasttrack for CentOS-5 ? I do see packages available from Red Hat, although I cannot find any fastrack SRPMs directory on ftp.redhat.com.

On Wed, Sep 3, 2008 at 8:03 PM, Dag Wieers dag@centos.org wrote:

On Mon, 1 Sep 2008, Karanbir Singh wrote:

...

David Hrbác wrote:

...

how come? What's the difference between C5 and C4 fasttrack repo? I don't remember having any announcement.

The C4 fasttrack repo is built in sync with upstream, there is no fasttrack on C5 ( go look at mirror.centos.org ).

Karanbir,

Is there a reason why there is no fasttrack for CentOS-5 ? I do see packages available from Red Hat, although I cannot find any fastrack SRPMs directory on ftp.redhat.com.

I think that is the major reason... if the packages are not available from ftp.redhat.com, they are harder to say they are build from upstream.

David Hrbáč wrote:

Karanbir Singh napsal(a):

...

There is now a perl package in the c5-testing repo that fix's these issues. Unless I hear reports of breakage in the next 24 hrs, will push that out via the fasttrack repo and make some announcements.

Also, if you do test it - and it does work fine : let us know about that too.

Karanbir, if we have axiom, I believe it's still valid, that we are lim 100 pct binary compatible with upstream, patched perl package should be pushed out via centosplus. David Hrbáč

How might a bug fix, and this one in particular, break binary compatibility? Does it change an API? Does it change the expected behaviour of PERL? (I'm assuming here that the current behaviour is _not_ expected behaviour).

David Hrbáč wrote:

John Summerfield napsal(a):

...

How might a bug fix, and this one in particular, break binary compatibility? Does it change an API? Does it change the expected behaviour of PERL? (I'm assuming here that the current behaviour is _not_ expected behaviour).

John, this behaviour is expected to be in RH, so I expect it to be in Centos. I do not want start a new flame, but this is not extra issue. RH has a lot of stupid bugs centos is not patching... Broken pythnon https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243909, missing header files https://bugzilla.redhat.com/show_bug.cgi?id=178417 to mention a few.

According to KS, "And no this wont be the first time there is a centos fix public before rh's either."

I guess having patched perl in testing is better idea than put it to centosplus.

_I_ would prefer to pick it up automatically, without having to make special configuration changes or use unusual commandline arguments. I'm looking for someone to explain why it should not be so, and "binary compatibility" isn't it. Nor does the overview at www.centos.org explain why not.

Notes to RHEL5 users. I'm sending this to the RHEL5 list because it affects RHEL5 users. The full discussion can be read from the archive for centos-devel at centos.org.

RH has promised its fix in RHEL5U3. CentOS has it now, the remaining discussion is how it's distributed. If you need it now, use the CentOS5 rpm and/or lean on RH.

Note to RHEL5 on Linux-390. The CentOS fixed rpm needs to be built for Zeds, but (probably) the CentOS src.rpm will build fine.

Note to SLES10 users on linux-390 I don't have a clue whether this applies to you, it could. Code to test it can be found in the archive I mentioned above.

Marcus Moeller wrote:

Dear John.

...

_I_ would prefer to pick it up automatically, without having to make special configuration changes or use unusual commandline arguments. I'm looking for someone to explain why it should not be so, and "binary compatibility" isn't it. Nor does the overview at www.centos.org explain why not.

It's not only about binary compatibility (of course this patch might not break with it). It's more about dividing from upstream.

That's not, afaics, a stated objective. There is a downside (prospective problems for users) in not fixing the problem for all C5 users.

What disadvantage is there to CentOS supplying its fix through the regular updates repo? MM, like me, doesn't see a problem with binary compatibility. The fix is available and implemented and (to some extent) tested. Apparently, RH has promised to fix it properly at some point in the future and the RH fix will automatically supersede the C fix.

As mentioned before RH will push out a fix sooner or later. Those systems that are affected (which is non of mine, at least) may be patched using testing or even fasttrack repo.

As I've said before, I don't think most people would know, unless they run over the problem in their own code, and if they do encounter it and use Google as I did, the fix they are more likely to find is "build your own perl."

I value compatibility with RH even though, in practice, it's probably not going to affect me directly - I'm unlikely to use commercial certified software - but I don't see a reason for retaining RH bugs just for compatibility.

Note, my C5 system doesn't even have a definition of a testing or fasttrack repo.

On Sun, Aug 31, 2008 at 01:53:55PM +0100, Karanbir Singh wrote:

There is now a perl package in the c5-testing repo that fix's these issues. Unless I hear reports of breakage in the next 24 hrs, will push that out via the fasttrack repo and make some announcements.

Also, if you do test it - and it does work fine : let us know about that too.

As others have reported, this seems to fix the main speed issues people were complaining about.

But it doesn't seem to have changed the overload referencing semantics that DBIx::Class::StartupCheck tests for - this still fails on the new perl:

perl -MDBIx::Class::StartupCheck -e1

WARNING: DBIx::Class::StartupCheck: This version of Perl is likely to exhibit extremely slow performance for certain critical operations. Please consider recompiling Perl. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=196836 and/or http://lists.scsys.co.uk/pipermail/dbix-class/2007-October/005119.html. You can suppress this message by setting DBIC_NO_WARN_BAD_PERL=1 in your environment.

You can also test this with this script:

#!/usr/bin/perl -w use strict; package Foo; use overload bool => sub { 0 }; sub quack { print "quacks like a Foo\n" } package main; my %hash; my $o1 = %hash; my $o2 = %hash; bless $o1, 'Foo'; print $o1 ? "o1 true\n" : "o1 false\n"; print $o2 ? "o2 true\n" : "o2 false\n"; $o2->quack();

which reports:

o1 false o2 false quacks like a Foo

on both the old and new CentOS perls, vs.

o1 false o2 true quacks like a Foo

on Ubuntu 5.8.8.

Karanbir, do you know if those fixes you used include the four changesets Nicholas references here?

http://use.perl.org/~nicholas/journal/37274

I'm not sure how much this actually matters in practice, but thought I'd point it out. It's at least confusing if the performance issue is fixed but DBIx::Class still complains.

Cheers, Gavin

Gavin,

Gavin Carr wrote:

As others have reported, this seems to fix the main speed issues people were complaining about.

But it doesn't seem to have changed the overload referencing semantics that DBIx::Class::StartupCheck tests for - this still fails on the new perl:

Two things, firstly - no one else in any of the bug reports has mentioned this DBIx issue - so, I am happy to ignore that in this bug case specifically since it does not break what was previous behavior.

Secondly, neither Nicholas nor Vipul have replied to my emails asking for help, and i think 4 days is a fair amount of time to timeout on.

So unless anyone has reason to not push these perl packages, I'd like to get them out there.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Dag Wieers wrote:

On Wed, 27 Aug 2008, Karanbir Singh wrote:

...

...

should explore the problem further with TUV and the CentOS community. If a fix is not forthcoming from TUV, I reluctantly suggest that we get together with the CentOS people and fork this portion of the distro, perhaps standardizing on Perl 5.10 . There are people in the Perl community ready to assist us.

While forking the whole perl subsection of the distro is a bit drastic, I am quite happy to have a perl in C5Plus. Does someone want to get in touch with Keith and get a summary on what needs fixing in this case ? Also - if the conversation was to take place on centos-devel list, would be much cooler.

Upstream have said the fix will be in 5U3, and considering that might be still a few months away, could we get something sorted before then ?

To be honest, if this problem was part of RHEL5 since its inception and only a few people until now have actually been bugged by it. I don't see a good reason to release something now only because someone was able to make a big poo out of it and got to slashdot.

We do not want to give attention-seekers more airtime, before we know it everyone who finds a bug starts shouting.

(Don't read me wrong, of course it should be fixed, I am just concerned about the motives and the generality of this bug wrt. other bugs.)

I understand from the MailScanner mailinglist that if you get hit by he bug SpamAssassin is going to be hit in a dramatic way. I understood that a normal 4 seconds of parsing becomes at least 40 minutes.

This means that if you get hit by it it will be extremely painful on a MailScanner system.

Hugo.

- -- hvdkooij@vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc

A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon?

Bored? Click on http://spamornot.org/ and rate those images.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Marcus Moeller wrote:

Dear Hugo.

I understand from the MailScanner mailinglist that if you get hit by he
bug SpamAssassin is going to be hit in a dramatic way. I understood that
a normal 4 seconds of parsing becomes at least 40 minutes.

I am using SA and amavid-new on several high traffic CentOS 5.2 mailservers without a problem.

The operative word here is IF you get hit.

The majority of the Centos 5 users with MailScanner is not hit but there 1 or confirmed cases where SA becomes unworkable.

If that happens to someone the owner propably does not care too much about the exact source of the fix. Just that they need it badlay because their email flow has just about stopped.

Hugo.

- -- hvdkooij@vanderkooij.org http://hugo.vanderkooij.org/ PGP/GPG? Use: http://hugo.vanderkooij.org/0x58F19981.asc

A: Yes. >Q: Are you sure? >>A: Because it reverses the logical flow of conversation. >>>Q: Why is top posting frowned upon?

Bored? Click on http://spamornot.org/ and rate those images.