Skip Menu |

This queue is for tickets about the libwww-perl CPAN distribution.

Report information
The Basics
Id: 74190
Status: resolved
Priority: 0/
Queue: libwww-perl

People
Owner: Nobody in particular
Requestors: mst [...] shadowcat.co.uk
Cc: ribasushi [...] leporine.io
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Why 5.8.8 ?
Date: Fri, 20 Jan 2012 20:28:00 +0000
To: bugs-libwww-perl [...] rt.cpan.org
From: Matt S Trout <mst [...] shadowcat.co.uk>
For sane unicode support, 5.8.5 is normal - which maintains compat with older RHELs and generally doesn't cause any compat issues. Requiring 5.8.8 instead just seems gratuitous unless there's a specific reason - in which case, please document the specific reason because none of the perl5 porters I've spoken to can figure it out. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.
On Fri Jan 20 15:32:20 2012, mst@shadowcat.co.uk wrote: Show quoted text
> For sane unicode support, 5.8.5 is normal - which maintains compat with > older RHELs and generally doesn't cause any compat issues. Requiring > 5.8.8 instead just seems gratuitous unless there's a specific reason > - in which case, please document the specific reason because none of > the perl5 porters I've spoken to can figure it out.
As soon as 6.0 was released, I complained about this, too, but got no response. In fact, I tested the entire thing successfully with 5.8.7. I just had to mangle the Makefiles.PL first. The modules themselves work fine in 5.8.7. All my modules that require LWP require Bundle::LWP5_837 when running under 5.8.7, to work around this. It’s a bit of a pain, though.
On Fri Jan 20 15:32:20 2012, mst@shadowcat.co.uk wrote: Show quoted text
> For sane unicode support, 5.8.5 is normal - which maintains compat with > older RHELs and generally doesn't cause any compat issues. Requiring > 5.8.8 instead just seems gratuitous unless there's a specific reason > - in which case, please document the specific reason because none of > the perl5 porters I've spoken to can figure it out. >
There is no reason. None at all. I bit the bullet and burned a ton of cycles to retest everything on my "smoker" (see list at end of message). There is absolutely no justification for any of these dependency bumps, which incidentally (instead of relying on cpan testers matrices) made it a multihour ordeal to bring things back to sanity. One single fix was required for URI on perls 5.8.1/5.8.2 to deal with a join() bug, other than that there were 0 (as in *zero*) changes, except correcting the Makefile.PLs. Please *apply all fixes* available in this git repo at your earliest convenience: https://github.com/ribasushi/libwww-perl-DEHATE/commits/master/ The methodology used for testing was roughly as follows: * Get the dists in question into a directory * Run the perl Makefile.PL && make in each * Set the env to export PERL5LIB=$(perl -MFile::Spec -e 'print( (join ":", map { File::Spec->rel2abs("$_/blib/lib"), File::Spec->rel2abs("$_/blib/arch") } glob("*") ) )') Then in the order of the git commits: * Enter directory * Run `perlbrew exec cpanm --installdeps .` or equivalent * Run `perlbrew exec bash -c '(perl Makefile.PL && make realclean && rm -f MANIFEST && perl Makefile.PL && make manifest) &>/dev/null && make disttest' | tee ../test_result.txt` - sometimes a 'perl -M5.8.1 -e 1 &&' was prepended to limit FAIL errors - for Net::HTTP perl Makefile.PL --live-tests && make test was used instead - Protocol::http10 had no tests at all, see commit message or methodology * Once the result was satisfactory the changes were committed by doing `echo -e "DISTNAME cleared for 5.8.1\n\nPERL5LIB=$PERL5LIB\n\n\n$(cat ../test_result.txt)" | git commit -F - Makefile.PL` That hopefully should be enough to take away any doubt about 5.8.1(or at times 5.6.2) support. My smoker env (perlbrew list): 5.10.0_EUMM 5.10.1 5.10.1_no_thr 5.12.1 5.12.1_no_thr 5.12.1_reb 5.12.2 5.12.2-RC1 5.12.3 5.12.4_dbg 5.13.10 5.13.11 5.13.11_rebuild 5.14.1_cat 5.14.1_dbg 5.14.1_EUMM 5.14.1_EUMM2 5.14.1_mb_dbg 5.14.1_thr 5.14.1_thr_dbg 5.14.1_thr_mb_dbg 5.14.2_thr_cln 5.15.0_nt 5.15.0_thr 5.15.1_nt 5.15.1_thr 5.15.2 5.15.3 5.15.4 5.15.5_thr 5.15.5_thr_mb 5.15.6 5.15.x_ino (5.15.1) 5.6.2 5.6.2_mb * 5.8.1 5.8.1_cln 5.8.1_dbg_mb 5.8.3 5.8.3_cln 5.8.3_dbg 5.8.3_dbg_thr 5.8.3_EUMM 5.8.4 5.8.5 5.8.5_cln 5.8.6 5.8.7 5.8.7_EUMM 5.8.8 5.8.9 5.8.9_EUMM 5.8.9_no_thr current (5.8.1) custom (5.14.2) /usr/bin/perl (5.14.2)
RT-Send-CC: sprout [...] cpan.org
An additional data point: when running against the modified LWP modules the current master of Catalyst passes its entire test suite under 5.8.3[1] (the minimum for Moose). Hopefully you will resolve this annoying issue soon. Cheers [1] http://git.shadowcat.co.uk/gitweb/gitweb.cgi?p=catagits/Catalyst-Runtime.git;a=commitdiff;h=0f6be50c90e64a135de4f8fd00703b3fc34f0fa5
perl-5.8.8 is 6 years old and seems to be what even RHEL5 ships. I don't have older perls than 5.8.8 available on my systems which is why I set that as the baseline for LWP6. I don't test with older versions. I also remember having answered many bug reports caused by the earlier 5.8.x releases so I was playing a bit safe. It might be that 5.8.5 (a 8 year old perl) is sane in as well. But I don't consider it "normal". Why do you consider it "normal"? Besides, why do you want to upgrade LWP if you don't want to even perform minor upgrades to your perl?
Subject: Re: [rt.cpan.org #74190] Why 5.8.8 ?
Date: Tue, 14 Feb 2012 01:47:54 +0000
To: Gisle_Aas via RT <bug-libwww-perl [...] rt.cpan.org>
From: Matt S Trout <mst [...] shadowcat.co.uk>
On Mon, Feb 13, 2012 at 07:03:25PM -0500, Gisle_Aas via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74190 > > > perl-5.8.8 is 6 years old and seems to be what even RHEL5 ships.
No, RHEL ships 5.8.5. Lots of Solaris systems still have 5.8.4. Enterprise support cycles suck sometimes. Show quoted text
> I don't have older perls than 5.8.8 available on my > systems which is why I set that as the baseline for LWP6. I don't test with older versions.
That's fine. We did. If you'd like to give RIBASUSHI and I co-maint rights so we have access to the RT queue we can triage these issues for you. Show quoted text
> I also remember having > answered many bug reports caused by the earlier 5.8.x releases so I was playing a bit safe. It might be that 5.8.5 (a 8 > year old perl) is sane in as well.
Excluding XS code, I've rarely encountered anything that worked on 5.8.8 and didn't on 5.8.5 as well, and 5.8.1 except for unicode edge cases. I restrict my own modules to 5.8.1, develop on 5.8.8, and let my community pick up the minor differences (usually RIBASUSHI fixes them before I even realise there's a problem). Show quoted text
> But I don't consider it "normal". Why do you consider it "normal"?
I don't. I do, however, consider 5.8.4 and 5.8.5 to both be perfectly viable perls, both of which Catalyst supported perfectly - and will again as soon as you remove the line of code that actively prevents it. Show quoted text
> Besides, why do you want to upgrade LWP if you don't want to even perform minor upgrades to your perl?
s/don't want to/can't/. I have users who want to do installs on 5.8.4/5 systems where corporate policies don't permit them to upgrade, but they *are* perfectly happy to test things and report bugs because they are aware that those perls are ancient. Basically, I have active users and contributors who're now forced to grovel back through CPAN for a version of LWP that installs on their systems, even though the latest version would run perfectly well if the Makefile.PL didn't place an arbitrary restriction on it. Your code currently runs perfectly back as far as 5.8.3. I am not asking you to install a perl that old, and I'm not asking you to fix bugs caused by perls that old yourself. I'm just asking you to stop crashing out the install. Please? -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.
On Mon Feb 13 19:03:24 2012, GAAS wrote: Show quoted text
> perl-5.8.8 is 6 years old and seems to be what even RHEL5 ships. I > don't have older perls than 5.8.8 available on my > systems which is why I set that as the baseline for LWP6. I don't > test with older versions. I also remember having > answered many bug reports caused by the earlier 5.8.x releases so I > was playing a bit safe. It might be that 5.8.5 (a 8 > year old perl) is sane in as well. But I don't consider it "normal". > Why do you consider it "normal"? > > Besides, why do you want to upgrade LWP if you don't want to even > perform minor upgrades to your perl?
Sometimes it’s a matter of installing it afresh in an existing system. Sometimes other modules rely on newer LWPs. What’s wrong with upgrading to 5.8.8? It introduced at least one new bug that 5.8.7 didn’t have.
I don't really care enough about RHEL5 to know what I'm talking about, but the boxes I have available here says they are "Red Hat Enterprise Linux Server release 5.7" and they come with "perl-5.8.8-32.el5_7.6". Isn't that RHEL5? Anyways, I'll move the requirement to 5.8.1 then since that appears to make at least a few loud people much happier. BTW, spammy bug reports with negative words like "hate" and "gratuitous" isn't really the right way to make me prioritize them. It just has the opposite effect.
CC: ribasushi [...] cpan.org
Subject: Re: [rt.cpan.org #74190] Why 5.8.8 ?
Date: Tue, 14 Feb 2012 20:18:56 +0000
To: Gisle_Aas via RT <bug-libwww-perl [...] rt.cpan.org>
From: Matt S Trout <mst [...] shadowcat.co.uk>
On Tue, Feb 14, 2012 at 02:44:30PM -0500, Gisle_Aas via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74190 > > > I don't really care enough about RHEL5 to know what I'm talking about
Which is why RIBASUSHI and I are offering to care on your behalf if required. That offers remains open, and we'll be keeping an eye on the testers matrix for older perls. Show quoted text
> Anyways, I'll move the requirement to 5.8.1 then since that appears to make at least a few loud people much happier.
Thank you very much! Show quoted text
> BTW, spammy bug reports with negative words like "hate" and "gratuitous" isn't really the right way to make me prioritize them. It just has the > opposite effect.
I am sorry for any offence caused unintentionally by my choice of vocabulary. But please don't call it 'spammy'. My original report was made with the best of intentions and phrased in a way that I believed would be read as total politeness, and your assumption of bad faith on my part is an unwarranted example of the exact sort of negativity that my choice of words appears to have accidentally projected. (and perhaps I shouldn't have written that final paragraph at all, but I found being called spammy under the circumstances to be genuinely upsetting and felt it was important to be candid about your words' effect on me as you have been about mine on you) -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.
What I regard as spammy is to get the same report on github, email, and here as RT#74199,74200,74201,...,7411 and then repeated as dependencies in this message. That part wasn't directed at you Matt. I'm probably to blame for this as as well, since I'm not as responsive on perl stuff as I wished I was. In my day work I'm not really using Perl any more, and the evening hours open for module support and hacking are too few to keep up. I also blame the Reader app on the iPad for my lack of remaining hacking time :-)
On Tue Feb 14 18:10:44 2012, GAAS wrote: Show quoted text
> What I regard as spammy is to get the same report on github, email, > and here as RT#74199,74200,74201,...,7411 and then repeated as > dependencies in this message. That part wasn't directed at you > Matt. > > I'm probably to blame for this as as well, since I'm not as responsive > on perl stuff as I wished I was. In my day work I'm not really > using Perl any more, and the evening hours open for module support > and hacking are too few to keep up. > I also blame the Reader app on the iPad for my lack of remaining > hacking time :-)
That would then be directed at me, and I concur that my delivery was not stellar. I blame my irritability threshold at the time[1], which I also recognize is not a very valid excuse. While my wording was not wise in any way, the rest was imho executed correctly. Tickets against the individual dists were opened because the minimum versions differ per-dist (some 5.8.1 some 5.6.2), and because each dist needed to be worked on individually, without even the need of doing it all at the same time. I find RT's linkage system to be very helpful with this kind of repetitive, on-and-off work. Github was chosen as an easy way to submit the massive logwork collected while testing everything. Also I did not use github to send any kind of messages - I simply referenced the pile of test logs in the RTs. All in all I apologize for the wording chosen to deliver my findings, it was not warranted. I also really appreciate you answering the concerns raised in this ticket, it makes those of us who care very happy and grateful. Thank you! [1] The hours spent testing and retesting stuff trying to find a justification for the dep bump. The fact that as a result I did not find anything set me off.
CC: ribasushi [...] cpan.org
Subject: Re: [rt.cpan.org #74190] Why 5.8.8 ?
Date: Tue, 14 Feb 2012 23:45:18 +0000
To: Gisle_Aas via RT <bug-libwww-perl [...] rt.cpan.org>
From: Matt S Trout <mst [...] shadowcat.co.uk>
On Tue, Feb 14, 2012 at 06:10:44PM -0500, Gisle_Aas via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74190 > > > What I regard as spammy is to get the same report on github, email, and here as RT#74199,74200,74201,...,7411 and then repeated as dependencies in this message. That part wasn't directed at you Matt.
Adding them as dependencies was so that it was easy for you to find them and close them all at once. Or at least that's why I assumed he'd done it. And we didn't start emailing you until the ticket had gone ignored for a bit. I did try and contact you sanely first. Show quoted text
> I'm probably to blame for this as as well, since I'm not as responsive on perl stuff as I wished I was. In my day work I'm not really using Perl any more, and the evening hours open for module support and hacking are too few to keep up. > I also blame the Reader app on the iPad for my lack of remaining hacking time :-)
Ok, once again: we both volunteer to do co-maint work. Create a github organisation or something so that we can give out commit bits, and let two experienced adopters of software with overloaded maintainers help take some of the strain for you. We're not *just* loud, you know :) -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.
I'm working my way through the modules. At this speed I should be done in a few more days. I've also created separate github repos for each of the dists. The arrangement with all the libwww-perl derived dists as branches of the libwww-perl repo confused too many, given the way github presents it and manages forks. Separate github issue queues for each dist should also be an improvement. I'm happy to give direct push access to the github repos for more people after I'm done with this cleanup round.
Subject: Re: [rt.cpan.org #74190] Why 5.8.8 ?
Date: Sat, 18 Feb 2012 13:15:36 +0000
To: Gisle_Aas via RT <bug-libwww-perl [...] rt.cpan.org>
From: Matt S Trout <mst [...] shadowcat.co.uk>
On Thu, Feb 16, 2012 at 05:52:36PM -0500, Gisle_Aas via RT wrote: Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=74190 > > > I'm working my way through the modules. At this speed I should be done in a few more days. I've also created separate github repos for each of the dists. The > arrangement with all the libwww-perl derived dists as branches of the libwww-perl repo confused too many, given the way github presents it and manages forks. > Separate github issue queues for each dist should also be an improvement. > > I'm happy to give direct push access to the github repos for more people after I'm done with this cleanup round.
Awesome. Awesome. Awesome. And I see the distributions are rolling onto CPAN, so I'm replying now so that there's no need to re-open this ticket just to send you a mail. Note: Your cpan address still appears to be activestate; probably worth updating that to be a little easier to get hold of (assuming I'm correct in thinking that's no longer the right one). But mostly: Sorry for chasing you round the houses over this, and thank you for accommodating us even if our presentation didn't come over optimally to begin with :) -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst commercial support, training and consultancy packages could help your team.
I think I'm done with this round of updates. Hopefully this thread will lead to some good things :-) I've set up https://github.com/libwww-perl as a github org and transferred the first repo to it. I've added Matt as contributor to the organization. That should allow you to push directly to the repo. Anybody else that wants access? I'm still doing (night-time) work for ActiveState, so my ActiveState email address still works.
I would love to have github access for fixing test failures—the one that comes to mind right now is the apache.t failure in LWP::Protocol::https that prevents installation if the building machine doesn't have internet access.
I added apeiron on github to the libwww-perl team. Hope that's you :-) I belive that the specific test failure for LWP::Protocol::https was fixed in the 6.03 release I uploaded 2 days ago.
On Sun Feb 19 06:16:23 2012, GAAS wrote: Show quoted text
> I think I'm done with this round of updates. Hopefully this thread > will lead to some good things > :-) > > I've set up https://github.com/libwww-perl as a github org and > transferred the first repo to it. > I've added Matt as contributor to the organization. That should allow > you to push directly to the > repo. Anybody else that wants access?
Hi! I don't mind being added for the occiasional cleanup work that may arise (ribasushi). Awesome work on clearing ehse issues up. I see you have not yet shipped an updated version of URI (RT#59274), so I can't yet test the whole shebang on a fresh old perl to see if it all holds together. Cheers!
On Sun Feb 19 06:16:23 2012, GAAS wrote: Show quoted text
> I think I'm done with this round of updates. Hopefully this thread > will lead to some good things > :-) >
I just tested on a bare 5.8.3 install (can't test 5.8.1 due to not yet fixed URI/RT#59274) - everything works except for a minor kink: LWP (and only LWP, the rest of the prereqs are fine) needs a more recent Test::Builder since old ones are not thread safe. The fix is to add a `require Test::Builder 0.22`, which was tested on another bare 5.8.3 to work as expected. Also it would be nice to remove the requirement line here: https://github.com/libwww-perl/libwww-perl/blob/master/README#L17 Thank you very much for making this possible, your work is very much appreciated \o/ Cheers!
I'll get around to it tomorrow (I think).
RT-Send-CC: sprout [...] cpan.org
Just retested everything on a fresh 5.8.1 - works like a charm. Please close this ticket, and thank you for your help! Cheers