From bugzilla at redhat.com Thu Mar 1 13:00:58 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 08:00:58 -0500 Subject: [Bug 230406] MakeMaker has perl.mak depending on non-existent /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h' In-Reply-To: Message-ID: <200703011300.l21D0wYj000972@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: MakeMaker has perl.mak depending on non-existent /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h' https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230406 ------- Additional Comments From vonbrand at inf.utfsm.cl 2007-03-01 08:00 EST ------- No, perl-devel is not installed, installing it fixes this. Perhaps MakeMaker (and other -devel stuff) should move over? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 13:12:58 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 08:12:58 -0500 Subject: [Bug 230406] MakeMaker has perl.mak depending on non-existent /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h' In-Reply-To: Message-ID: <200703011312.l21DCw1E001564@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: MakeMaker has perl.mak depending on non-existent /usr/lib/perl5/5.8.8/i386-linux-thread-multi/CORE/config.h' https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230406 ------- Additional Comments From tcallawa at redhat.com 2007-03-01 08:12 EST ------- We're still trying to get perl-devel sorted out. Suggestions of what should move into perl-devel would be GREATLY appreciated. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 15:49:00 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 10:49:00 -0500 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200703011549.l21Fn0ZH014592@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-RPM2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 ------- Additional Comments From rnorwood at redhat.com 2007-03-01 10:48 EST ------- Sorry, dropped the ball on this one - I'll look into it today. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 16:21:29 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 11:21:29 -0500 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200703011621.l21GLTeB016898@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-RPM2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|paul at city-fan.org |rnorwood at redhat.com Flag| |fedora-cvs? ------- Additional Comments From rnorwood at redhat.com 2007-03-01 11:21 EST ------- New Package CVS Request ======================= Package Name: perl-RPM2 Short Description: Perl bindings for RPM Owners: rnorwood at redhat.com Branches: FC-5 FC-6 InitialCC: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 18:57:08 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 13:57:08 -0500 Subject: [Bug 230608] New: missing config.h in latest -14 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 Summary: missing config.h in latest -14 Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: normal Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: cbalint at redhat.com QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: missing config.h i think latest -devel doesnt ship that header file. Version-Release number of selected component (if applicable): perl-5.8.8-14.fc7 How reproducible: -- Steps to Reproduce: [root at rezso SPECS]# rpm --root=/var/lib/mock/fedora-development-i386-core/root/ -ql perl | grep config.h | grep CORE [root at rezso SPECS]# rpm --root=/var/lib/mock/fedora-development-x86_64-core/root/ -ql perl | grep config.h | grep CORE /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/config.h /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/uconfig.h [root at rezso SPECS]# rpm --root=/var/lib/mock/fedora-development-x86_64-core/root/ -q perl perl-5.8.8-12.fc7 [root at rezso SPECS]# rpm --root=/var/lib/mock/fedora-development-i386-core/root/ -q perl perl-5.8.8-14.fc7 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 18:58:15 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 13:58:15 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: Message-ID: <200703011858.l21IwFqA004687@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 cbalint at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |227646 nThis| | -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 19:03:44 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 14:03:44 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: Message-ID: <200703011903.l21J3iZn005413@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 cbalint at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|227646 |222042 nThis| | -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 1 19:38:46 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 14:38:46 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: Message-ID: <200703011938.l21JckAF010053@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- Balint, Yes, this is related to our splitting out perl-devel in -14 - 'yum install perl-devel' should fix the problem. See bug #226276 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 2 01:20:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 1 Mar 2007 20:20:52 -0500 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200703020120.l221KqJj006601@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-RPM2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 petersen at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+ ------- Additional Comments From petersen at redhat.com 2007-03-01 20:20 EST ------- Added fedora-perl-devel-list at redhat.com in CC too. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Fri Mar 2 06:09:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 07:09:27 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <200703011938.l21JckAF010053@bugzilla.redhat.com> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> Message-ID: <1172815768.26830.51.camel@mccallum.corsepiu.local> On Thu, 2007-03-01 at 14:38 -0500, bugzilla at redhat.com wrote: > Please do not reply directly to this email. All additional > comments should be made in the comments box of this bug report. > > Summary: missing config.h in latest -14 > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 > > > > > > ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- > Balint, > > Yes, this is related to our splitting out perl-devel in -14 - 'yum install > perl-devel' should fix the problem. See bug #226276 AFAIS, this change seems to break building of any perl-module. => All perl modules' spec files from now on would require to change all perl-modules to "BuildRequire: perl-devel" - Are you seriously wanting this? As this thing doesn't seem to be baked yet[1], and as I don't want to see FE-6 and FE-5 being locked out from updates, for now, I will ignore this issue on rawhide, i.e. you will likely see broken EVRs between rawhide and older FE, on my perl-modules, soon. Ralf [1] Why is such a massive change being introduced such kind of late in a release cycle? IMO, it's way to late, and should be postponed to F8 once things have been sorted out. From bugzilla at redhat.com Fri Mar 2 06:43:12 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 2 Mar 2007 01:43:12 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: Message-ID: <200703020643.l226hC4l023868@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 rc040203 at freenet.de changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |230689 nThis| | -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 2 06:43:10 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 2 Mar 2007 01:43:10 -0500 Subject: [Bug 230689] New: Missing config.h Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230689 Summary: Missing config.h Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: normal Component: perl-File-Copy-Recursive AssignedTo: rc040203 at freenet.de ReportedBy: rc040203 at freenet.de QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com This is meant to be a tracker bug to myself Description of problem: http://buildsys.fedoraproject.org/logs/fedora-development-extras/28596-perl-File-Copy-Recursive-0.31-1.fc7/ Version-Release number of selected component (if applicable): perl-File-Copy-Recursive-0.31-1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Fri Mar 2 06:45:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 07:45:07 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172815768.26830.51.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> Message-ID: <1172817907.26830.62.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 07:09 +0100, Ralf Corsepius wrote: > On Thu, 2007-03-01 at 14:38 -0500, bugzilla at redhat.com wrote: > > Please do not reply directly to this email. All additional > > comments should be made in the comments box of this bug report. > > > > Summary: missing config.h in latest -14 > > > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 > > > > > > > > > > > > ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- > > Balint, > > > > Yes, this is related to our splitting out perl-devel in -14 - 'yum install > > perl-devel' should fix the problem. See bug #226276 > > AFAIS, this change seems to break building of any perl-module. > > => All perl modules' spec files from now on would require to change all > perl-modules to "BuildRequire: perl-devel" - > Are you seriously wanting this? FWIW: A work-around would be to put "perl-devel" into the default set package of the FC7-buildsystem Ralf From bugzilla at redhat.com Fri Mar 2 11:19:13 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 2 Mar 2007 06:19:13 -0500 Subject: [Bug 230689] Missing config.h In-Reply-To: Message-ID: <200703021119.l22BJDSR007332@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Missing config.h https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230689 Bug 230689 depends on bug 230608, which changed state. Bug 230608 Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NOTABUG Status|NEW |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 2 11:18:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 2 Mar 2007 06:18:52 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: Message-ID: <200703021118.l22BIq0O007308@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 cbalint at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG ------- Additional Comments From cbalint at redhat.com 2007-03-02 06:18 EST ------- dohh ... sorry ! I was _very_ dumb at that late hours ... didnt notice that. thx ! -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From paul at city-fan.org Fri Mar 2 13:05:41 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 02 Mar 2007 13:05:41 +0000 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172815768.26830.51.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> Message-ID: <45E82125.903@city-fan.org> Ralf Corsepius wrote: > On Thu, 2007-03-01 at 14:38 -0500, bugzilla at redhat.com wrote: >> Please do not reply directly to this email. All additional >> comments should be made in the comments box of this bug report. >> >> Summary: missing config.h in latest -14 >> >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 >> >> >> >> >> >> ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- >> Balint, >> >> Yes, this is related to our splitting out perl-devel in -14 - 'yum install >> perl-devel' should fix the problem. See bug #226276 > > AFAIS, this change seems to break building of any perl-module. > > => All perl modules' spec files from now on would require to change all > perl-modules to "BuildRequire: perl-devel" - > Are you seriously wanting this? > > As this thing doesn't seem to be baked yet[1], and as I don't want to > see FE-6 and FE-5 being locked out from updates, for now, I will ignore > this issue on rawhide, i.e. you will likely see broken EVRs between > rawhide and older FE, on my perl-modules, soon. The same issue will affect the grepmail update I'm just about to do as well. I'm not adding the perl=devel buildreq just yet until a firm decision on whether all modules have to BR: perl=devel is made. > [1] Why is such a massive change being introduced such kind of late in a > release cycle? IMO, it's way to late, and should be postponed to F8 once > things have been sorted out. It's clearly come about as a result of the perl spec cleanup during the merge review, but I think splitting out perl-devel at this point is a bit late given the number of packages that will need changing (unless as Ralf suggests, the hack of adding perl-devel to the FC7 buildroot is made). Paul. From tcallawa at redhat.com Fri Mar 2 16:17:24 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 02 Mar 2007 10:17:24 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <45E82125.903@city-fan.org> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45E82125.903@city-fan.org> Message-ID: <1172852244.3355.17.camel@localhost.localdomain> On Fri, 2007-03-02 at 13:05 +0000, Paul Howarth wrote: > Ralf Corsepius wrote: > >> ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- > >> Balint, > >> > >> Yes, this is related to our splitting out perl-devel in -14 - 'yum install > >> perl-devel' should fix the problem. See bug #226276 > > > > AFAIS, this change seems to break building of any perl-module. > > > > => All perl modules' spec files from now on would require to change all > > perl-modules to "BuildRequire: perl-devel" - > > Are you seriously wanting this? > > > > As this thing doesn't seem to be baked yet[1], and as I don't want to > > see FE-6 and FE-5 being locked out from updates, for now, I will ignore > > this issue on rawhide, i.e. you will likely see broken EVRs between > > rawhide and older FE, on my perl-modules, soon. > > The same issue will affect the grepmail update I'm just about to do as > well. I'm not adding the perl=devel buildreq just yet until a firm > decision on whether all modules have to BR: perl=devel is made. > > > [1] Why is such a massive change being introduced such kind of late in a > > release cycle? IMO, it's way to late, and should be postponed to F8 once > > things have been sorted out. > > It's clearly come about as a result of the perl spec cleanup during the > merge review, but I think splitting out perl-devel at this point is a > bit late given the number of packages that will need changing (unless as > Ralf suggests, the hack of adding perl-devel to the FC7 buildroot is made). I don't see any fault in adding perl-devel to the FC7 buildroot, with the caveat that it will not be there in FC8+. Thoughts? ~spot From paul at city-fan.org Fri Mar 2 17:47:28 2007 From: paul at city-fan.org (Paul Howarth) Date: Fri, 02 Mar 2007 17:47:28 +0000 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172852244.3355.17.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> Message-ID: <1172857648.16210.1.camel@metropolis.intra.city-fan.org> On Fri, 2007-03-02 at 10:17 -0600, Tom 'spot' Callaway wrote: > On Fri, 2007-03-02 at 13:05 +0000, Paul Howarth wrote: > > Ralf Corsepius wrote: > > > >> ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- > > >> Balint, > > >> > > >> Yes, this is related to our splitting out perl-devel in -14 - 'yum install > > >> perl-devel' should fix the problem. See bug #226276 > > > > > > AFAIS, this change seems to break building of any perl-module. > > > > > > => All perl modules' spec files from now on would require to change all > > > perl-modules to "BuildRequire: perl-devel" - > > > Are you seriously wanting this? > > > > > > As this thing doesn't seem to be baked yet[1], and as I don't want to > > > see FE-6 and FE-5 being locked out from updates, for now, I will ignore > > > this issue on rawhide, i.e. you will likely see broken EVRs between > > > rawhide and older FE, on my perl-modules, soon. > > > > The same issue will affect the grepmail update I'm just about to do as > > well. I'm not adding the perl=devel buildreq just yet until a firm > > decision on whether all modules have to BR: perl=devel is made. > > > > > [1] Why is such a massive change being introduced such kind of late in a > > > release cycle? IMO, it's way to late, and should be postponed to F8 once > > > things have been sorted out. > > > > It's clearly come about as a result of the perl spec cleanup during the > > merge review, but I think splitting out perl-devel at this point is a > > bit late given the number of packages that will need changing (unless as > > Ralf suggests, the hack of adding perl-devel to the FC7 buildroot is made). > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > the caveat that it will not be there in FC8+. Thoughts? Works for me (literally, in my own buildsystem... as well as figuratively). Paul. From rc040203 at freenet.de Fri Mar 2 18:18:37 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 02 Mar 2007 19:18:37 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172852244.3355.17.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> Message-ID: <1172859517.26830.255.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 10:17 -0600, Tom 'spot' Callaway wrote: > On Fri, 2007-03-02 at 13:05 +0000, Paul Howarth wrote: > > Ralf Corsepius wrote: > > > >> ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- > > >> Balint, > > >> > > >> Yes, this is related to our splitting out perl-devel in -14 - 'yum install > > >> perl-devel' should fix the problem. See bug #226276 > > > > > > AFAIS, this change seems to break building of any perl-module. > > > > > > => All perl modules' spec files from now on would require to change all > > > perl-modules to "BuildRequire: perl-devel" - > > > Are you seriously wanting this? > > > > > > As this thing doesn't seem to be baked yet[1], and as I don't want to > > > see FE-6 and FE-5 being locked out from updates, for now, I will ignore > > > this issue on rawhide, i.e. you will likely see broken EVRs between > > > rawhide and older FE, on my perl-modules, soon. > > > > The same issue will affect the grepmail update I'm just about to do as > > well. I'm not adding the perl=devel buildreq just yet until a firm > > decision on whether all modules have to BR: perl=devel is made. > > > > > [1] Why is such a massive change being introduced such kind of late in a > > > release cycle? IMO, it's way to late, and should be postponed to F8 once > > > things have been sorted out. > > > > It's clearly come about as a result of the perl spec cleanup during the > > merge review, but I think splitting out perl-devel at this point is a > > bit late given the number of packages that will need changing (unless as > > Ralf suggests, the hack of adding perl-devel to the FC7 buildroot is made). > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > the caveat that it will not be there in FC8+. Thoughts? IMO, this perl-devel package isn't baked, yet. I needs to prove at least some amount of longevity/sustainablity and meaningfulness. E.g. * should _all_ perl packages now BR: perl-devel? * should config.h remain part of perl? * Why does perl need config.h (a c-header) when building noarch packages, which do not use a compiler at all? Therefore, I think forcing package to depend on perl-devel would be premature. Adding perl-devel to the buildroot would at least help to postpone the consequences of perl-devel. Ralf From rnorwood at redhat.com Fri Mar 2 18:27:01 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 02 Mar 2007 13:27:01 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172817907.26830.62.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 02 Mar 2007 07:45:07 +0100") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <1172817907.26830.62.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Fri, 2007-03-02 at 07:09 +0100, Ralf Corsepius wrote: >> On Thu, 2007-03-01 at 14:38 -0500, bugzilla at redhat.com wrote: >> > Please do not reply directly to this email. All additional >> > comments should be made in the comments box of this bug report. >> > >> > Summary: missing config.h in latest -14 >> > >> > >> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 >> > >> > >> > >> > >> > >> > ------- Additional Comments From rnorwood at redhat.com 2007-03-01 14:38 EST ------- >> > Balint, >> > >> > Yes, this is related to our splitting out perl-devel in -14 - 'yum install >> > perl-devel' should fix the problem. See bug #226276 >> >> AFAIS, this change seems to break building of any perl-module. >> >> => All perl modules' spec files from now on would require to change all >> perl-modules to "BuildRequire: perl-devel" - >> Are you seriously wanting this? > FWIW: A work-around would be to put "perl-devel" into the default set > package of the FC7-buildsystem Hey Ralf, a little background: Tom Callaway reviewed the perl spec file for me - it was such a mess that he decided to basically rewrite it from scratch. It is much, much nicer now, but one of the changes he made was to include a -devel subpackage, which make sense, but causes problems such as these. The package even needs a little more work because some additional things could be split out instead of just the .h files. Or, we could roll everything back into 'perl' and put an Obsoletes: perl-devel for awhile to take care of people who have perl-devel installed. What do you guys think is best? I like the -devel idea, but if you think it will be more trouble than it's worth, we can roll it back into 'perl'. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From jkeating at redhat.com Fri Mar 2 16:28:08 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 11:28:08 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172852244.3355.17.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> Message-ID: <200703021128.08773.jkeating@redhat.com> On Friday 02 March 2007 11:17:24 Tom 'spot' Callaway wrote: > I don't see any fault in adding perl-devel to the FC7 buildroot, with > the caveat that it will not be there in FC8+. Thoughts? I'd rather not change things multiple times. We're still not too the Feature Freeze of Fedora 7, the development cycle is just barely half over, so there should be no issue with changing all the perl modules to follow this new perl split. Why does Ralf think it hasn't been baked yet? I'm missing that context. Perl is only in the buildroot now because it is needed by rpm-build. Should that go away, perl wouldn't be in the buildroot at all, and wouldn't be added. I see no problem with making this change to the perl modules that wish to build in development+ beyond. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Mar 2 18:59:54 2007 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 2 Mar 2007 13:59:54 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172859517.26830.255.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172852244.3355.17.camel@localhost.localdomain> <1172859517.26830.255.camel@mccallum.corsepiu.local> Message-ID: <200703021359.54347.jkeating@redhat.com> On Friday 02 March 2007 13:18:37 Ralf Corsepius wrote: > Therefore, I think forcing package to depend on perl-devel would be > premature. Adding perl-devel to the buildroot would at least help to > postpone the consequences of perl-devel. No, it'll just hide them and nobody will be motivated to work on this again. I'm entirely uninterested in buildsystem hacks to keep packagers from having to do a little bit of work. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rc040203 at freenet.de Sat Mar 3 05:20:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 03 Mar 2007 06:20:23 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <200703021128.08773.jkeating@redhat.com> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> <200703021128.08773.jkeating@redhat.com> Message-ID: <1172899224.26830.335.camel@mccallum.corsepiu.local> On Fri, 2007-03-02 at 11:28 -0500, Jesse Keating wrote: > On Friday 02 March 2007 11:17:24 Tom 'spot' Callaway wrote: > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > > the caveat that it will not be there in FC8+. Thoughts? > > I'd rather not change things multiple times. Well, exactly the reason why I would like to see perl-devel in FC7's buildroot. It avoids forcing packagers to change their packages NOW. Remember: Adding perl-devel to the buildroot affects one person (you). Not adding it and affects 100s of packages and dozens of packagers. > Why does Ralf think it hasn't been baked yet? I'm missing that context. This change causes most (all?) perl modules and applications using perl (comprising noarch packages) to depend on perl's config.h at build time. The primary question to clarify would be: What is the cause, why (esp. noarch) perl-modules now require a c-header (perl's config.h) and (thereby gcc) to build? [1] The next question would be: What is the correct step to resolve this issue inside of RPM spec? At least I don't know the answer (yet) and see a need for investigations. Adding "BR: perl-devel" could be the answer, but the answer could also be along the lines of * The split is illegitimate, config.h must stay part of the main perl-package * Missing (indirect) dep somewhere else (e.g. inside of another perl-module) * Bug in one of the perl-modules being used to process Makefile.PLs * bug in perl ... I see many possibilities. I.e. ATM, a recommendation for "BR: perl-devel" seems premature to me. Ralf [1] Note: noarch packages requires a c-header and gcc to build! From tcallawa at redhat.com Sat Mar 3 06:13:36 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 03 Mar 2007 00:13:36 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172899224.26830.335.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> <200703021128.08773.jkeating@redhat.com> <1172899224.26830.335.camel@mccallum.corsepiu.local> Message-ID: <1172902416.5447.1.camel@localhost.localdomain> On Sat, 2007-03-03 at 06:20 +0100, Ralf Corsepius wrote: > On Fri, 2007-03-02 at 11:28 -0500, Jesse Keating wrote: > > On Friday 02 March 2007 11:17:24 Tom 'spot' Callaway wrote: > > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > > > the caveat that it will not be there in FC8+. Thoughts? > > > > I'd rather not change things multiple times. > Well, exactly the reason why I would like to see perl-devel in FC7's > buildroot. It avoids forcing packagers to change their packages NOW. > > Remember: Adding perl-devel to the buildroot affects one person (you). > Not adding it and affects 100s of packages and dozens of packagers. > > > Why does Ralf think it hasn't been baked yet? I'm missing that context. > > This change causes most (all?) perl modules and applications using perl > (comprising noarch packages) to depend on perl's config.h at build time. > > The primary question to clarify would be: > > What is the cause, why (esp. noarch) perl-modules now require a c-header > (perl's config.h) and (thereby gcc) to build? [1] Well, fwiw, they seem to have required this before, the -devel split just made it more apparent. When I rewrote the perl spec, I didn't make any code changes, just spec file cleanups. ~spot From rc040203 at freenet.de Sat Mar 3 06:44:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 03 Mar 2007 07:44:13 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172902416.5447.1.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> <200703021128.08773.jkeating@redhat.com> <1172899224.26830.335.camel@mccallum.corsepiu.local> <1172902416.5447.1.camel@localhost.localdomain> Message-ID: <1172904253.26830.345.camel@mccallum.corsepiu.local> On Sat, 2007-03-03 at 00:13 -0600, Tom 'spot' Callaway wrote: > On Sat, 2007-03-03 at 06:20 +0100, Ralf Corsepius wrote: > > On Fri, 2007-03-02 at 11:28 -0500, Jesse Keating wrote: > > > On Friday 02 March 2007 11:17:24 Tom 'spot' Callaway wrote: > > > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > > > > the caveat that it will not be there in FC8+. Thoughts? > > > > > > I'd rather not change things multiple times. > > Well, exactly the reason why I would like to see perl-devel in FC7's > > buildroot. It avoids forcing packagers to change their packages NOW. > > > > Remember: Adding perl-devel to the buildroot affects one person (you). > > Not adding it and affects 100s of packages and dozens of packagers. > > > > > Why does Ralf think it hasn't been baked yet? I'm missing that context. > > > > This change causes most (all?) perl modules and applications using perl > > (comprising noarch packages) to depend on perl's config.h at build time. > > > > The primary question to clarify would be: > > > > What is the cause, why (esp. noarch) perl-modules now require a c-header > > (perl's config.h) and (thereby gcc) to build? [1] > > Well, fwiw, they seem to have required this before, the -devel split > just made it more apparent. I just tried to investigate on of my currently broken packages, and see a file dependency on config.h in ExtUtils::MakeMaker generated Makefiles. i.e. no compilation is involved, and no dependency on gcc or any library, this Makefile simply depends on the _file_ config.h. I haven't yet checked what it is used for. > When I rewrote the perl spec, I didn't make > any code changes, just spec file cleanups. Well, yes, you made an implicit dep visible. The question is "which dependency" and is kind of package split useful (There is no doubt that a split between a "c-devel environment" and a run-time environment is useful.) Ralf From rc040203 at freenet.de Sun Mar 4 06:47:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 04 Mar 2007 07:47:13 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172904253.26830.345.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <45E82125.903@city-fan.org> <1172852244.3355.17.camel@localhost.localdomain> <200703021128.08773.jkeating@redhat.com> <1172899224.26830.335.camel@mccallum.corsepiu.local> <1172902416.5447.1.camel@localhost.localdomain> <1172904253.26830.345.camel@mccallum.corsepiu.local> Message-ID: <1172990834.26830.361.camel@mccallum.corsepiu.local> On Sat, 2007-03-03 at 07:44 +0100, Ralf Corsepius wrote: > On Sat, 2007-03-03 at 00:13 -0600, Tom 'spot' Callaway wrote: > > On Sat, 2007-03-03 at 06:20 +0100, Ralf Corsepius wrote: > > > On Fri, 2007-03-02 at 11:28 -0500, Jesse Keating wrote: > > > > On Friday 02 March 2007 11:17:24 Tom 'spot' Callaway wrote: > > > > > I don't see any fault in adding perl-devel to the FC7 buildroot, with > > > > > the caveat that it will not be there in FC8+. Thoughts? > > > > > > > > I'd rather not change things multiple times. > > > Well, exactly the reason why I would like to see perl-devel in FC7's > > > buildroot. It avoids forcing packagers to change their packages NOW. > > > > > > Remember: Adding perl-devel to the buildroot affects one person (you). > > > Not adding it and affects 100s of packages and dozens of packagers. > > > > > > > Why does Ralf think it hasn't been baked yet? I'm missing that context. > > > > > > This change causes most (all?) perl modules and applications using perl > > > (comprising noarch packages) to depend on perl's config.h at build time. > > > > > > The primary question to clarify would be: > > > > > > What is the cause, why (esp. noarch) perl-modules now require a c-header > > > (perl's config.h) and (thereby gcc) to build? [1] > > > > Well, fwiw, they seem to have required this before, the -devel split > > just made it more apparent. > > I just tried to investigate on of my currently broken packages, and see > a file dependency on config.h in ExtUtils::MakeMaker generated > Makefiles. I've found at least one packaging-bug wrt. the perl-devel split-out, along the lines of what I wrote above: There is an indirect circular build-time dependency between "perl" and "perl-devel", for ExtUtils::MakeMaker based packages: Proof: * ExtUtils::MakeMaker based perl-modules contain a hidden built-time dependency through their Makefile.PL containing: use ExtUtils::MakeMaker; * ExtUtils::MakeMaker has a dependency on "config.h" # grep -R config.h /usr/lib/perl5/5.8.8/ExtUtils /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:CONFIGDEP = $(PERL_ARCHLIB)$(DFSEP)Config.pm $(PERL_INC)$(DFSEP)config.h /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm: -f $self->catfile($dir,"config_h.SH") /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:# We do NOT just update config.h because that is not sufficient. /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:# An out of date config.h is not fatal but complains loudly! /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm:$(PERL_INC)/config.h: $(PERL_SRC)/config.sh /usr/lib/perl5/5.8.8/ExtUtils/MM_Unix.pm: -$(NOECHO) $(ECHO) "Warning: $(PERL_INC)/config.h out of date with $(PERL_SRC)/config.sh"; false * config.h is part of perl-devel => circular dependency between "perl" and "perl-devel" I.e. in a perfect world all MakeMaker-based perl-packages should BuildRequires: perl(ExtUtils::MakeMaker) and perl(ExtUtils::MakeMaker) would have to Require: perl-devel So, one approach I could imagine, would be to split out ExtUtils::MakeMaker from the main perl package. Ralf From bugzilla at redhat.com Sun Mar 4 20:17:44 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 4 Mar 2007 15:17:44 -0500 Subject: [Bug 230933] New: perl-Set-IntSpan-1.10 is available Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230933 Summary: perl-Set-IntSpan-1.10 is available Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: medium Component: perl-Set-IntSpan AssignedTo: ville.skytta at iki.fi ReportedBy: fevapp at o2.pl QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com perl-Set-IntSpan-1.10 is already available. Repo version is 1.09. Please update the package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From wtogami at redhat.com Mon Mar 5 15:24:04 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Mar 2007 10:24:04 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1172815768.26830.51.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> Message-ID: <45EC3614.3020007@redhat.com> Ralf Corsepius wrote: > > As this thing doesn't seem to be baked yet[1], and as I don't want to > see FE-6 and FE-5 being locked out from updates, for now, I will ignore > this issue on rawhide, i.e. you will likely see broken EVRs between > rawhide and older FE, on my perl-modules, soon. Why broken EVR's? > > Ralf > > [1] Why is such a massive change being introduced such kind of late in a > release cycle? IMO, it's way to late, and should be postponed to F8 once > things have been sorted out. Yes, why? Warren Togami wtogami at redhat.com From paul at city-fan.org Mon Mar 5 15:38:55 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 05 Mar 2007 15:38:55 +0000 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <45EC3614.3020007@redhat.com> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> Message-ID: <45EC398F.7090400@city-fan.org> Warren Togami wrote: > Ralf Corsepius wrote: >> >> As this thing doesn't seem to be baked yet[1], and as I don't want to >> see FE-6 and FE-5 being locked out from updates, for now, I will ignore >> this issue on rawhide, i.e. you will likely see broken EVRs between >> rawhide and older FE, on my perl-modules, soon. > > Why broken EVR's? Most perl module packages can use a common spec file across all branches, except this is now broken in devel since perl-devel is needed to build even noarch perl-based packages. So Ralf isn't updating perl modules in devel until this is resolved, with the result that updated packages in branches for older releases have higher EVRs than the equivalent packages in devel. I'm doing likewise for the moment. Paul. From bugzilla at redhat.com Mon Mar 5 15:39:45 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 5 Mar 2007 10:39:45 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: Message-ID: <200703051539.l25Fdjge005289@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: missing config.h in latest -14 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230608 ------- Additional Comments From wtogami at redhat.com 2007-03-05 10:39 EST ------- Just talked with Robin. Proposed to make this this transition smoother in the future is to add "Provides: perl-devel" to the older versions of the perl package when perl is updated in those distros. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Mon Mar 5 16:07:02 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Mar 2007 17:07:02 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <45EC398F.7090400@city-fan.org> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> Message-ID: <1173110822.25839.59.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 15:38 +0000, Paul Howarth wrote: > Warren Togami wrote: > > Ralf Corsepius wrote: > >> > >> As this thing doesn't seem to be baked yet[1], and as I don't want to > >> see FE-6 and FE-5 being locked out from updates, for now, I will ignore > >> this issue on rawhide, i.e. you will likely see broken EVRs between > >> rawhide and older FE, on my perl-modules, soon. > > > > Why broken EVR's? I should have been more explicit. I was referring to EVR's between different versions of Fedora. ATM, you'll see EVRs of some of my perl-modules in FC6 carrying higher EVRs than that in rawhide. > Most perl module packages can use a common spec file across all > branches, except this is now broken in devel since perl-devel is needed > to build even noarch perl-based packages. So Ralf isn't updating perl > modules in devel until this is resolved, Exactly, I do not want to change the 45+ perl-modules, I maintain, before the outcome of this issue is clear (A one-time change/mass-rebuild would be OK with me - once the outcome is clear) > with the result that updated > packages in branches for older releases have higher EVRs than the > equivalent packages in devel. I'm doing likewise for the moment. Ralf From rnorwood at redhat.com Mon Mar 5 16:08:17 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 11:08:17 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <45EC398F.7090400@city-fan.org> (Paul Howarth's message of "Mon, 05 Mar 2007 15:38:55 +0000") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> Message-ID: Paul Howarth writes: > Warren Togami wrote: >> Ralf Corsepius wrote: >>> >>> As this thing doesn't seem to be baked yet[1], and as I don't want to >>> see FE-6 and FE-5 being locked out from updates, for now, I will ignore >>> this issue on rawhide, i.e. you will likely see broken EVRs between >>> rawhide and older FE, on my perl-modules, soon. >> Why broken EVR's? > > Most perl module packages can use a common spec file across all > branches, except this is now broken in devel since perl-devel is > needed to build even noarch perl-based packages. So Ralf isn't > updating perl modules in devel until this is resolved, with the result > that updated packages in branches for older releases have higher EVRs > than the equivalent packages in devel. I'm doing likewise for the > moment. If we retroactively add a 'Provides: perl-devel' to versions of perl in older distributions, will that help? -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rc040203 at freenet.de Mon Mar 5 16:18:41 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 05 Mar 2007 17:18:41 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> Message-ID: <1173111521.25839.65.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 11:08 -0500, Robin Norwood wrote: > Paul Howarth writes: > > > Warren Togami wrote: > >> Ralf Corsepius wrote: > >>> > >>> As this thing doesn't seem to be baked yet[1], and as I don't want to > >>> see FE-6 and FE-5 being locked out from updates, for now, I will ignore > >>> this issue on rawhide, i.e. you will likely see broken EVRs between > >>> rawhide and older FE, on my perl-modules, soon. > >> Why broken EVR's? > > > > Most perl module packages can use a common spec file across all > > branches, except this is now broken in devel since perl-devel is > > needed to build even noarch perl-based packages. So Ralf isn't > > updating perl modules in devel until this is resolved, with the result > > that updated packages in branches for older releases have higher EVRs > > than the equivalent packages in devel. I'm doing likewise for the > > moment. > > If we retroactively add a 'Provides: perl-devel' to versions of perl in > older distributions, will that help? It will solve the *.spec portability issue, but ... the core question still remains: Is this split "correct" and "sustainable" or simply broken? ATM, IMO, the outcome is still unclear. E.g. wrt to the MakeMaker issue, the "correct solution" would be to let a ExtUtils::MakeMaker spec "Requires: perl-devel", and to let all perl-modules using ExtUtils::MakeMaker at build-time "BuildRequires: perl(ExtUtils::MakeMaker)". I had wanted to have deeper look into this problem throughout today, but haven't found the time for it (and my day is almost over). Ralf From rnorwood at redhat.com Mon Mar 5 16:28:33 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 11:28:33 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173111521.25839.65.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Mon, 05 Mar 2007 17:18:41 +0100") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Mon, 2007-03-05 at 11:08 -0500, Robin Norwood wrote: [...] >> If we retroactively add a 'Provides: perl-devel' to versions of perl in >> older distributions, will that help? > It will solve the *.spec portability issue, but ... the core question > still remains: Is this split "correct" and "sustainable" or simply > broken? > > ATM, IMO, the outcome is still unclear. Yes, I meant assuming we decide to 'go forward' with this change. > E.g. wrt to the MakeMaker issue, the "correct solution" would be to let > a ExtUtils::MakeMaker spec "Requires: perl-devel", and to let all > perl-modules using ExtUtils::MakeMaker at build-time > "BuildRequires: perl(ExtUtils::MakeMaker)". > > I had wanted to have deeper look into this problem throughout today, but > haven't found the time for it (and my day is almost over). This definitely needs more attention. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rnorwood at redhat.com Mon Mar 5 16:40:50 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 11:40:50 -0500 Subject: Mea Culpa Message-ID: Hi, I wanted to send out a note separate from the technical discussion. I didn't fully think through the implications before I built the new package into rawhide, and broke everyone's builds. I'm sorry for the trouble this change has caused for y'all. For now, let's finish the debate about the change, make a decision, and get this thing done one way or another. We'll end with a better, stronger, faster perl when we're done. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From tcallawa at redhat.com Mon Mar 5 16:42:29 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Mar 2007 10:42:29 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> Message-ID: <1173112949.1407.43.camel@localhost.localdomain> On Mon, 2007-03-05 at 11:28 -0500, Robin Norwood wrote: > Ralf Corsepius writes: > > > On Mon, 2007-03-05 at 11:08 -0500, Robin Norwood wrote: > > [...] > > >> If we retroactively add a 'Provides: perl-devel' to versions of perl in > >> older distributions, will that help? > > It will solve the *.spec portability issue, but ... the core question > > still remains: Is this split "correct" and "sustainable" or simply > > broken? > > > > ATM, IMO, the outcome is still unclear. > > Yes, I meant assuming we decide to 'go forward' with this change. > > > E.g. wrt to the MakeMaker issue, the "correct solution" would be to let > > a ExtUtils::MakeMaker spec "Requires: perl-devel", and to let all > > perl-modules using ExtUtils::MakeMaker at build-time > > "BuildRequires: perl(ExtUtils::MakeMaker)". > > > > I had wanted to have deeper look into this problem throughout today, but > > haven't found the time for it (and my day is almost over). > > This definitely needs more attention. Well, as Joe pointed out (when he wasn't name-calling), CPAN does depend on ExtUtils::MakeMaker. So, we can do the following: * Move ExtUtils::MakeMaker to its own package. Move CPAN to its own package. Have the CPAN package depend on ExtUtils::MakeMaker, have the ExtUtils::MakeMaker package depend on perl-devel. In functionality, this brings us back to where we began, except that now, default installs (just perl) will not get CPAN. * Move ExtUtils::MakeMaker and CPAN to perl-devel. Again, default installs (just perl) won't get CPAN. * The third option is to move config.h back into perl, and document this as an exception case. ~spot From wtogami at redhat.com Mon Mar 5 16:51:06 2007 From: wtogami at redhat.com (Warren Togami) Date: Mon, 05 Mar 2007 11:51:06 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173112949.1407.43.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> Message-ID: <45EC4A7A.7080406@redhat.com> Tom 'spot' Callaway wrote: > * The third option is to move config.h back into perl, and document this > as an exception case. Have we figured any (real) cases where moving config.h to its own package actually helps us? Warren Togami wtogami at redhat.com From tcallawa at redhat.com Mon Mar 5 17:11:16 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Mar 2007 11:11:16 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173112949.1407.43.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> Message-ID: <1173114676.1407.53.camel@localhost.localdomain> On Mon, 2007-03-05 at 10:42 -0600, Tom 'spot' Callaway wrote: > Well, as Joe pointed out (when he wasn't name-calling), CPAN does depend > on ExtUtils::MakeMaker. > > So, we can do the following: > > * Move ExtUtils::MakeMaker to its own package. Move CPAN to its own > package. Have the CPAN package depend on ExtUtils::MakeMaker, have the > ExtUtils::MakeMaker package depend on perl-devel. > > In functionality, this brings us back to where we began, except that > now, default installs (just perl) will not get CPAN. > > * Move ExtUtils::MakeMaker and CPAN to perl-devel. Again, default > installs (just perl) won't get CPAN. > > * The third option is to move config.h back into perl, and document this > as an exception case. CPAN isn't the only thing: [spot at localhost perl-5.8.8]$ grep -r "require ExtUtils::MakeMaker" * lib/CPAN.pm: require ExtUtils::MakeMaker; lib/CPAN.pm: require ExtUtils::MakeMaker; lib/ExtUtils/Embed.pm:#require ExtUtils::MakeMaker; lib/ExtUtils/Embed.pm: require ExtUtils::MakeMaker; lib/ExtUtils/t/backwards.t:require ExtUtils::MakeMaker; lib/ExtUtils/MM.pm:require ExtUtils::MakeMaker; utils/perlbug.PL: require ExtUtils::MakeMaker; so, we'd need to handle ExtUtils::Embed and perlbug too. :/ perlbug is really the hardest one. I think we really want that to be in the base perl package. The "third option" above, is looking more and more like the cleanest fix to me. Thoughts? ~spot From rgarciasuarez at gmail.com Mon Mar 5 17:17:22 2007 From: rgarciasuarez at gmail.com (Rafael Garcia-Suarez) Date: Mon, 5 Mar 2007 18:17:22 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173114676.1407.53.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> Message-ID: On 05/03/07, Tom 'spot' Callaway wrote: > CPAN isn't the only thing: > > [spot at localhost perl-5.8.8]$ grep -r "require ExtUtils::MakeMaker" * > lib/CPAN.pm: require ExtUtils::MakeMaker; > lib/CPAN.pm: require ExtUtils::MakeMaker; > lib/ExtUtils/Embed.pm:#require ExtUtils::MakeMaker; > lib/ExtUtils/Embed.pm: require ExtUtils::MakeMaker; > lib/ExtUtils/t/backwards.t:require ExtUtils::MakeMaker; > lib/ExtUtils/MM.pm:require ExtUtils::MakeMaker; > utils/perlbug.PL: require ExtUtils::MakeMaker; > > so, we'd need to handle ExtUtils::Embed and perlbug too. :/ > > perlbug is really the hardest one. I think we really want that to be in > the base perl package. Look closer. EU::MM is only needed by perlbug on... MacOS classic. I think you can ditch that dependency :) From rnorwood at redhat.com Mon Mar 5 17:20:37 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 12:20:37 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173114676.1407.53.camel@localhost.localdomain> (Tom Callaway's message of "Mon, 05 Mar 2007 11:11:16 -0600") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> Message-ID: "Tom 'spot' Callaway" writes: > On Mon, 2007-03-05 at 10:42 -0600, Tom 'spot' Callaway wrote: > >> Well, as Joe pointed out (when he wasn't name-calling), CPAN does depend >> on ExtUtils::MakeMaker. >> >> So, we can do the following: >> >> * Move ExtUtils::MakeMaker to its own package. Move CPAN to its own >> package. Have the CPAN package depend on ExtUtils::MakeMaker, have the >> ExtUtils::MakeMaker package depend on perl-devel. >> >> In functionality, this brings us back to where we began, except that >> now, default installs (just perl) will not get CPAN. >> >> * Move ExtUtils::MakeMaker and CPAN to perl-devel. Again, default >> installs (just perl) won't get CPAN. >> >> * The third option is to move config.h back into perl, and document this >> as an exception case. > > CPAN isn't the only thing: > > [spot at localhost perl-5.8.8]$ grep -r "require ExtUtils::MakeMaker" * > lib/CPAN.pm: require ExtUtils::MakeMaker; > lib/CPAN.pm: require ExtUtils::MakeMaker; > lib/ExtUtils/Embed.pm:#require ExtUtils::MakeMaker; > lib/ExtUtils/Embed.pm: require ExtUtils::MakeMaker; > lib/ExtUtils/t/backwards.t:require ExtUtils::MakeMaker; > lib/ExtUtils/MM.pm:require ExtUtils::MakeMaker; > utils/perlbug.PL: require ExtUtils::MakeMaker; > > so, we'd need to handle ExtUtils::Embed and perlbug too. :/ > > perlbug is really the hardest one. I think we really want that to be in > the base perl package. > > The "third option" above, is looking more and more like the cleanest fix > to me. Thoughts? It might be. I can see putting MakeMaker and CPAN into perl-devel, but perlbug really seems to me to belong in the main perl package. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From cweyl at alumni.drew.edu Mon Mar 5 16:27:18 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 5 Mar 2007 08:27:18 -0800 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <45EC398F.7090400@city-fan.org> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> Message-ID: <7dd7ab490703050827g1e53ca5dnff59c7981b0af05c@mail.gmail.com> On 3/5/07, Paul Howarth wrote: > Warren Togami wrote: > > Ralf Corsepius wrote: > >> > >> As this thing doesn't seem to be baked yet[1], and as I don't want to > >> see FE-6 and FE-5 being locked out from updates, for now, I will ignore > >> this issue on rawhide, i.e. you will likely see broken EVRs between > >> rawhide and older FE, on my perl-modules, soon. > > > > Why broken EVR's? > > Most perl module packages can use a common spec file across all > branches, except this is now broken in devel since perl-devel is needed > to build even noarch perl-based packages. So Ralf isn't updating perl > modules in devel until this is resolved, with the result that updated > packages in branches for older releases have higher EVRs than the > equivalent packages in devel. I'm doing likewise for the moment. As am I. So, it seems to me that splitting the .h files off into a perl-devel package has introduced a number of issues that could be interpreted as being anywhere in a range of "surprise!" to bug. * ExtUtils::MakeMaker (at the least) depends on config.h, in -devel, but is in core w/o a dep. * End-users, not just developers/packagers, will be surprised by ExtUtils::MakeMaker's being present but broken. (e.g. someone trying to install extra modules from CPAN.) * This is a departure from long standing practice in packaging perl/perl-packages. * A new buildreq will have to be added to every perl module (~530 in extras) * Every perl-based package will require an examination to ensure that they will not require perl-devel at run time. (I'd imagine most of the ExtUtils packages would, but...) * -devel contains /usr/lib/perl5/%{version}/Encode/*.h, which breaks the ability of a package to buildrequires against perl(Encode). I'm all for the division of devel and runtime packages; but in this case I think we're going too far. We've split off what, as near as I can tell, is a goodly number of .h files that do not introduce any additional package deps, breaking at least two core modules, for the reason "the guidelines say so". --or at least I haven't been able to discern a better one. But as even the guidelines admonish they are the beginning, not the ending of packaging[1], can we not admit that core perl is both a devel and a user package, even after splitting out the .h's? What's next after this? Will we need to go out and split every .h file from every perl package out, breaking the clean, simple and effective method of simply needing to br a perl(foo) symbol? Unless there's something I'm missing here -- entirely possible -- I'd ask that this change be reverted, -devel be subsumed again by core, and the core perl package be additionally flagged to provide perl-devel (so as to not break any packages already merged to conform). -Chris [1] "This is a collection of some guidelines for writing Fedora packages. These guidelines are considered to be good practices by existing Fedora packagers and QA people. If you are new to Fedora, you should try to stick as closely to these guidelines as possible. When you have gained some experience working with Fedora packages, you will know when to deviate from them." -- Chris Weyl Ex astris, scientia From tcallawa at redhat.com Mon Mar 5 19:33:29 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Mar 2007 13:33:29 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> Message-ID: <1173123209.1407.77.camel@localhost.localdomain> On Mon, 2007-03-05 at 18:17 +0100, Rafael Garcia-Suarez wrote: > On 05/03/07, Tom 'spot' Callaway wrote: > > CPAN isn't the only thing: > > > > [spot at localhost perl-5.8.8]$ grep -r "require ExtUtils::MakeMaker" * > > lib/CPAN.pm: require ExtUtils::MakeMaker; > > lib/CPAN.pm: require ExtUtils::MakeMaker; > > lib/ExtUtils/Embed.pm:#require ExtUtils::MakeMaker; > > lib/ExtUtils/Embed.pm: require ExtUtils::MakeMaker; > > lib/ExtUtils/t/backwards.t:require ExtUtils::MakeMaker; > > lib/ExtUtils/MM.pm:require ExtUtils::MakeMaker; > > utils/perlbug.PL: require ExtUtils::MakeMaker; > > > > so, we'd need to handle ExtUtils::Embed and perlbug too. :/ > > > > perlbug is really the hardest one. I think we really want that to be in > > the base perl package. > > Look closer. EU::MM is only needed by perlbug on... MacOS classic. I > think you can ditch that dependency :) Well, thats a relief. :) So, we'd need: perl-ExtUtils-MakeMaker perl-ExtUtils-Embed perl-CPAN (which requires) \perl-Test-Harness >= 2.62 (core perl provided 2.56) We can either entirely extract these components from the core tree before building core perl, or we can just let them build and not package them (the simpler approach, and the one I have initially chosen). But when I did that, I hit problems: /usr/bin/perlcc needs ExtUtils::Embed (circular dep?) /usr/bin/perlivp needs ExtUtils::Installed (circular dep?) /usr/bin/h2xs needs ExtUtils::MakeMaker (circular dep?) /usr/bin/libnetcfg needs ExtUtils::MakeMaker (circular dep?) I don't think there is going to be a good way to pull these items out of core without introducing circular deps. ~spot From rnorwood at redhat.com Mon Mar 5 20:38:55 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 05 Mar 2007 15:38:55 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173123209.1407.77.camel@localhost.localdomain> (Tom Callaway's message of "Mon, 05 Mar 2007 13:33:29 -0600") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> Message-ID: "Tom 'spot' Callaway" writes: > On Mon, 2007-03-05 at 18:17 +0100, Rafael Garcia-Suarez wrote: >> On 05/03/07, Tom 'spot' Callaway wrote: >> > CPAN isn't the only thing: >> > >> > [spot at localhost perl-5.8.8]$ grep -r "require ExtUtils::MakeMaker" * >> > lib/CPAN.pm: require ExtUtils::MakeMaker; >> > lib/CPAN.pm: require ExtUtils::MakeMaker; >> > lib/ExtUtils/Embed.pm:#require ExtUtils::MakeMaker; >> > lib/ExtUtils/Embed.pm: require ExtUtils::MakeMaker; >> > lib/ExtUtils/t/backwards.t:require ExtUtils::MakeMaker; >> > lib/ExtUtils/MM.pm:require ExtUtils::MakeMaker; >> > utils/perlbug.PL: require ExtUtils::MakeMaker; >> > >> > so, we'd need to handle ExtUtils::Embed and perlbug too. :/ >> > >> > perlbug is really the hardest one. I think we really want that to be in >> > the base perl package. >> >> Look closer. EU::MM is only needed by perlbug on... MacOS classic. I >> think you can ditch that dependency :) > > Well, thats a relief. :) > > So, we'd need: > > perl-ExtUtils-MakeMaker > perl-ExtUtils-Embed > perl-CPAN > (which requires) > \perl-Test-Harness >= 2.62 (core perl provided 2.56) > > We can either entirely extract these components from the core tree > before building core perl, or we can just let them build and not package > them (the simpler approach, and the one I have initially chosen). > > But when I did that, I hit problems: > /usr/bin/perlcc needs ExtUtils::Embed (circular dep?) > /usr/bin/perlivp needs ExtUtils::Installed (circular dep?) > /usr/bin/h2xs needs ExtUtils::MakeMaker (circular dep?) > /usr/bin/libnetcfg needs ExtUtils::MakeMaker (circular dep?) > > I don't think there is going to be a good way to pull these items out of > core without introducing circular deps. Spot, Jesse Keating, and I just had a call to try to work these issues out. Spot is going to continue to look into what needs to be done to split out perl-devel. Unfortunately, it looks like perl may be too tangled to allow us to make this split clean and still include things that are considered 'core' perl by most people - such as CPAN, for instance. I would argue that CPAN *is* a 'devel' utility, but most people would expect it to be installed on a system whenever perl is, which is fair. If he can get things in shape by tomorrow, we may be able to keep perl-devel split out, perhaps with a 'Requires: perl-devel' in F7's perl and a 'Provides: perl-devel' in the perl for previous releases to keep modules building and working in both cases with the same spec file. However, we should work towards removing the Requires: perl-devel from perl at some point in the future, since that way it's not much better than just having everything in perl. If he can't get things working in relatively short order, we will look at just rolling perl-devel back into perl and adding a Provides: perl-devel. We'll consider the fact that perl isn't split out into perl-devel as a bug to be fixed in Fedora 8. Thanks for your patience. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From steve at silug.org Tue Mar 6 01:24:17 2007 From: steve at silug.org (Steven Pritchard) Date: Mon, 5 Mar 2007 19:24:17 -0600 Subject: Pre-review: parrot and pugs In-Reply-To: <20060627203020.GA31510@osiris.silug.org> References: <20060627203020.GA31510@osiris.silug.org> Message-ID: <20070306012417.GA21218@osiris.silug.org> On Tue, Jun 27, 2006 at 03:30:20PM -0500, Steven Pritchard wrote: > If any of you happen to be interested in Perl6 development, I have > very lightly tested parrot and pugs packages that I'll be submitting > for formal review soon: OK, maybe not "soon". Let's go with "eventually". The last version of parrot I tried to build gave me fits, so in the mean time I've rebuilt pugs without parrot embedding enabled. http://ftp.kspei.com/pub/steve/rpms/perl-Perl6-Pugs-6.2.13-1.src.rpm http://ftp.kspei.com/pub/steve/rpms/perl-Perl6-Pugs/perl-Perl6-Pugs.spec > I haven't run these through rpmlint or built them with mock yet, so > I'm sure there will be some issues. This does build successfully in mock, but rpmlint screams, which is why I'm holding off submitting it for real. :-) While the package definitely still has issues, it does work nicely. $ pugs -e 'my @n=<>; "@n[]".say;' Perl6 is cool Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From rc040203 at freenet.de Tue Mar 6 13:31:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 14:31:13 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> Message-ID: <1173187874.25839.109.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 15:38 -0500, Robin Norwood wrote: > "Tom 'spot' Callaway" writes: > > > On Mon, 2007-03-05 at 18:17 +0100, Rafael Garcia-Suarez wrote: > >> On 05/03/07, Tom 'spot' Callaway wrote: > >> > CPAN isn't the only thing: > >> > > >> > [spot at localhost perl-5.8.8]$ grep -r "require ExtUtils::MakeMaker" * > >> > lib/CPAN.pm: require ExtUtils::MakeMaker; > >> > lib/CPAN.pm: require ExtUtils::MakeMaker; > >> > lib/ExtUtils/Embed.pm:#require ExtUtils::MakeMaker; > >> > lib/ExtUtils/Embed.pm: require ExtUtils::MakeMaker; > >> > lib/ExtUtils/t/backwards.t:require ExtUtils::MakeMaker; > >> > lib/ExtUtils/MM.pm:require ExtUtils::MakeMaker; > >> > utils/perlbug.PL: require ExtUtils::MakeMaker; > >> > > >> > so, we'd need to handle ExtUtils::Embed and perlbug too. :/ > >> > > >> > perlbug is really the hardest one. I think we really want that to be in > >> > the base perl package. > >> > >> Look closer. EU::MM is only needed by perlbug on... MacOS classic. I > >> think you can ditch that dependency :) > > > > Well, thats a relief. :) > > > > So, we'd need: > > > > perl-ExtUtils-MakeMaker > > perl-ExtUtils-Embed > > perl-CPAN > > (which requires) > > \perl-Test-Harness >= 2.62 (core perl provided 2.56) > > > > We can either entirely extract these components from the core tree > > before building core perl, or we can just let them build and not package > > them (the simpler approach, and the one I have initially chosen). > > > > But when I did that, I hit problems: > > /usr/bin/perlcc needs ExtUtils::Embed (circular dep?) > > /usr/bin/perlivp needs ExtUtils::Installed (circular dep?) > > /usr/bin/h2xs needs ExtUtils::MakeMaker (circular dep?) > > /usr/bin/libnetcfg needs ExtUtils::MakeMaker (circular dep?) > > > > I don't think there is going to be a good way to pull these items out of > > core without introducing circular deps. Below is a patch proposal to address this issue: It is based on moving EU::MM and CPAN to perl-devel and then tracing all deps between the main perl package and perl-devel. Unless I missed something, this should resolve the deps issues related to EU::MM. Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-spec.diff Type: text/x-patch Size: 2411 bytes Desc: not available URL: -------------- next part -------------- %{_bindir}/instmodsh %{_libdir}/perl5/%{version}/ExtUtils/PATCHING %{_libdir}/perl5/%{version}/ExtUtils/NOTES %dir %{_libdir}/perl5/%{version}/ExtUtils/Command/ %{_libdir}/perl5/%{version}/ExtUtils/Command/MM.pm %{_libdir}/perl5/%{version}/ExtUtils/Installed.pm %{_libdir}/perl5/%{version}/ExtUtils/Install.pm %dir %{_libdir}/perl5/%{version}/ExtUtils/Liblist/ %{_libdir}/perl5/%{version}/ExtUtils/Liblist/Kid.pm %{_libdir}/perl5/%{version}/ExtUtils/Liblist.pm %dir %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker/ %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker/bytes.pm %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker/Config.pm %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker/FAQ.pod %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker.pm %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker/Tutorial.pod %{_libdir}/perl5/%{version}/ExtUtils/MakeMaker/vmsish.pm %{_libdir}/perl5/%{version}/ExtUtils/Manifest.pm %{_libdir}/perl5/%{version}/ExtUtils/MANIFEST.SKIP %{_libdir}/perl5/%{version}/ExtUtils/Mkbootstrap.pm %{_libdir}/perl5/%{version}/ExtUtils/Mksymlists.pm %{_libdir}/perl5/%{version}/ExtUtils/MM_* %{_libdir}/perl5/%{version}/ExtUtils/MM.pm %{_libdir}/perl5/%{version}/ExtUtils/MY.pm %{_libdir}/perl5/%{version}/ExtUtils/Packlist.pm %{_libdir}/perl5/%{version}/ExtUtils/testlib.pm %{_mandir}/man1/instmodsh.1* %{_mandir}/man3/ExtUtils::Command::MM.3pm* %{_mandir}/man3/ExtUtils::Install.3pm* %{_mandir}/man3/ExtUtils::Installed.3pm* %{_mandir}/man3/ExtUtils::Liblist.3pm* %{_mandir}/man3/ExtUtils::MakeMaker.3pm* %{_mandir}/man3/ExtUtils::MakeMaker::bytes.3pm* %{_mandir}/man3/ExtUtils::MakeMaker::Config.3pm* %{_mandir}/man3/ExtUtils::MakeMaker::FAQ.3pm* %{_mandir}/man3/ExtUtils::MakeMaker::Tutorial.3pm* %{_mandir}/man3/ExtUtils::MakeMaker::vmsish.3pm* %{_mandir}/man3/ExtUtils::Manifest.3pm* %{_mandir}/man3/ExtUtils::Mkbootstrap.3pm* %{_mandir}/man3/ExtUtils::Mksymlists.3pm* %{_mandir}/man3/ExtUtils::MM_*.3pm* %{_mandir}/man3/ExtUtils::MM.3pm* %{_mandir}/man3/ExtUtils::MY.3pm* %{_mandir}/man3/ExtUtils::Packlist.3pm* %{_mandir}/man3/ExtUtils::testlib.3pm* From rc040203 at freenet.de Tue Mar 6 13:40:13 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 14:40:13 +0100 Subject: Should perl-devel Obsolete perl? Message-ID: <1173188413.25839.118.camel@mccallum.corsepiu.local> Hi, Another issue related to the perl-devel split out: The files having been contained in "perl < *-14", now are distributed through "perl+perl-devel" IMO, perl-devel >= *-14 therefore should Obsoletes: perl < 4:5.8.8-14 to guarantee an update/upgrade without functional regressions. Unfortunately: Such a change has dramatic effects on yum: It causes yum to iterate through all perl(...) deps. Ralf From tcallawa at redhat.com Mon Mar 5 22:30:07 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Mon, 05 Mar 2007 16:30:07 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> Message-ID: <1173133807.1407.83.camel@localhost.localdomain> On Mon, 2007-03-05 at 15:38 -0500, Robin Norwood wrote: > Spot, Jesse Keating, and I just had a call to try to work these issues > out. Spot is going to continue to look into what needs to be done to > split out perl-devel. Unfortunately, it looks like perl may be too > tangled to allow us to make this split clean and still include things > that are considered 'core' perl by most people - such as CPAN, for > instance. I would argue that CPAN *is* a 'devel' utility, but most > people would expect it to be installed on a system whenever perl is, > which is fair. > > If he can get things in shape by tomorrow, we may be able to keep > perl-devel split out, perhaps with a 'Requires: perl-devel' in F7's perl > and a 'Provides: perl-devel' in the perl for previous releases to keep > modules building and working in both cases with the same spec file. Attached to this email is a new perl spec file: - ExtUtils::Embed, ExtUtils::MakeMaker, Test::Harness, CPAN have all gone into -devel - perlcc, perlivp, h2xs, libnetcfg are in -devel too (they depend on the above modules) - encode.h is back in the main perl package (it makes sense to me to have Encode in base perl) Thoughts? Suggestions are welcomed. ~spot -------------- next part -------------- A non-text attachment was scrubbed... Name: perl.spec Type: text/x-rpm-spec Size: 42044 bytes Desc: not available URL: From tcallawa at redhat.com Tue Mar 6 14:52:20 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Mar 2007 08:52:20 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173187874.25839.109.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173187874.25839.109.camel@mccallum.corsepiu.local> Message-ID: <1173192740.14777.12.camel@localhost.localdomain> On Tue, 2007-03-06 at 14:31 +0100, Ralf Corsepius wrote: > Below is a patch proposal to address this issue: > > It is based on moving EU::MM and CPAN to perl-devel and then tracing all > deps between the main perl package and perl-devel. > > Unless I missed something, this should resolve the deps issues related > to EU::MM. Hmm, I know I sent an email out yesterday with a proposed updated spec, but Evolution must have eaten it (stupid evo). The new spec moves all of: ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, and Test::Harness into devel, along with the items that depend on them (perlcc, perlivp, h2xs, libnetcfg). I put all of Encode back in base, because it seemed like something that might get used by runtime perl bits, but if you disagree, I'd like to know (I've not made up my mind either way on that one). Note that I'm doing the /usr/lib... instead of %{_libdir} on purpose, otherwise, x86_64 doesn't find these files (since they're noarch bits buried in arch specific core, that's where they always end up). ~spot -------------- next part -------------- A non-text attachment was scrubbed... Name: perl.spec Type: text/x-rpm-spec Size: 42289 bytes Desc: not available URL: From rnorwood at redhat.com Tue Mar 6 15:43:27 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 06 Mar 2007 10:43:27 -0500 Subject: Should perl-devel Obsolete perl? In-Reply-To: <1173188413.25839.118.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 06 Mar 2007 14:40:13 +0100") References: <1173188413.25839.118.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > Hi, > > Another issue related to the perl-devel split out: > > The files having been contained in "perl < *-14", now are > distributed through "perl+perl-devel" > > IMO, perl-devel >= *-14 therefore should > Obsoletes: perl < 4:5.8.8-14 > to guarantee an update/upgrade without functional regressions. > > Unfortunately: Such a change has dramatic effects on yum: It causes yum > to iterate through all perl(...) deps. This doesn't seem right to me anyway. perl-devel doesn't obsolete older versions of perl since it doesn't replace their functionality. perl+perl-devel does 'obsolete' older versions of perl, but rpm can't really express that. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rgarciasuarez at gmail.com Tue Mar 6 15:47:34 2007 From: rgarciasuarez at gmail.com (Rafael Garcia-Suarez) Date: Tue, 6 Mar 2007 16:47:34 +0100 Subject: Should perl-devel Obsolete perl? In-Reply-To: References: <1173188413.25839.118.camel@mccallum.corsepiu.local> Message-ID: On 06/03/07, Robin Norwood wrote: > > IMO, perl-devel >= *-14 therefore should > > Obsoletes: perl < 4:5.8.8-14 > > to guarantee an update/upgrade without functional regressions. > > > > Unfortunately: Such a change has dramatic effects on yum: It causes yum > > to iterate through all perl(...) deps. > > This doesn't seem right to me anyway. perl-devel doesn't obsolete older > versions of perl since it doesn't replace their functionality. > perl+perl-devel does 'obsolete' older versions of perl, but rpm can't > really express that. Say that the new perl-devel Conflicts with perl < 4:5.8.8-14 ? From rc040203 at freenet.de Tue Mar 6 15:48:44 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 16:48:44 +0100 Subject: Should perl-devel Obsolete perl? In-Reply-To: References: <1173188413.25839.118.camel@mccallum.corsepiu.local> Message-ID: <1173196124.25839.130.camel@mccallum.corsepiu.local> On Tue, 2007-03-06 at 10:43 -0500, Robin Norwood wrote: > Ralf Corsepius writes: > > > Hi, > > > > Another issue related to the perl-devel split out: > > > > The files having been contained in "perl < *-14", now are > > distributed through "perl+perl-devel" > > > > IMO, perl-devel >= *-14 therefore should > > Obsoletes: perl < 4:5.8.8-14 > > to guarantee an update/upgrade without functional regressions. > > > > Unfortunately: Such a change has dramatic effects on yum: It causes yum > > to iterate through all perl(...) deps. > > This doesn't seem right to me anyway. perl-devel doesn't obsolete older > versions of perl since it doesn't replace their functionality. It does. Several perl(..) modules formerly having been contained in perl, in future will be provided by perl-devel (e.g. perl(Extutils::MakeMaker)). > perl+perl-devel does 'obsolete' older versions of perl, but rpm can't > really express that. It can - Let perl-devel: Obsoletes: perl < 4:5.8.8-14 perl will provide "perl-4:5.8.8-14" and perl-devel will provide "perl-devel-4:5.8.8-14" i.e. after and update the "obsoletes" won't have any influence any more. Ralf From tcallawa at redhat.com Tue Mar 6 15:56:13 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Mar 2007 09:56:13 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173192740.14777.12.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173187874.25839.109.camel@mccallum.corsepiu.local> <1173192740.14777.12.camel@localhost.localdomain> Message-ID: <1173196573.14777.23.camel@localhost.localdomain> On Tue, 2007-03-06 at 08:52 -0600, Tom 'spot' Callaway wrote: > On Tue, 2007-03-06 at 14:31 +0100, Ralf Corsepius wrote: > > > Below is a patch proposal to address this issue: > > > > It is based on moving EU::MM and CPAN to perl-devel and then tracing all > > deps between the main perl package and perl-devel. > > > > Unless I missed something, this should resolve the deps issues related > > to EU::MM. > > Hmm, I know I sent an email out yesterday with a proposed updated spec, > but Evolution must have eaten it (stupid evo). > > The new spec moves all of: ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, > and Test::Harness into devel, along with the items that depend on them > (perlcc, perlivp, h2xs, libnetcfg). I put all of Encode back in base, > because it seemed like something that might get used by runtime perl > bits, but if you disagree, I'd like to know (I've not made up my mind > either way on that one). > > Note that I'm doing the /usr/lib... instead of %{_libdir} on purpose, > otherwise, x86_64 doesn't find these files (since they're noarch bits > buried in arch specific core, that's where they always end up). The spec I sent out this morning is the most accurate one (I caught some minor issues late last night). ~spot From rnorwood at redhat.com Tue Mar 6 16:44:44 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 06 Mar 2007 11:44:44 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173192740.14777.12.camel@localhost.localdomain> (Tom Callaway's message of "Tue, 06 Mar 2007 08:52:20 -0600") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173187874.25839.109.camel@mccallum.corsepiu.local> <1173192740.14777.12.camel@localhost.localdomain> Message-ID: "Tom 'spot' Callaway" writes: > On Tue, 2007-03-06 at 14:31 +0100, Ralf Corsepius wrote: > >> Below is a patch proposal to address this issue: >> >> It is based on moving EU::MM and CPAN to perl-devel and then tracing all >> deps between the main perl package and perl-devel. >> >> Unless I missed something, this should resolve the deps issues related >> to EU::MM. > > Hmm, I know I sent an email out yesterday with a proposed updated spec, > but Evolution must have eaten it (stupid evo). Actually it was held back from the list due to size limits. I sent it through this morning. > The new spec moves all of: ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, > and Test::Harness into devel, along with the items that depend on them > (perlcc, perlivp, h2xs, libnetcfg). I put all of Encode back in base, > because it seemed like something that might get used by runtime perl > bits, but if you disagree, I'd like to know (I've not made up my mind > either way on that one). This seems like the right split to me - I'm still a little nervous about CPAN, but I think after people get used to it, it makes sense, and yum install perl(CPAN) should get it for them. I wonder if explicitly providing something called 'cpan' would help - so 'yum install cpan' would work as well. > Note that I'm doing the /usr/lib... instead of %{_libdir} on purpose, > otherwise, x86_64 doesn't find these files (since they're noarch bits > buried in arch specific core, that's where they always end up). Yes, that's really annoying - I wish there were a 'better way'. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rc040203 at freenet.de Tue Mar 6 16:53:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 06 Mar 2007 17:53:22 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173187874.25839.109.camel@mccallum.corsepiu.local> <1173192740.14777.12.camel@localhost.localdomain> Message-ID: <1173200002.25839.137.camel@mccallum.corsepiu.local> On Tue, 2007-03-06 at 11:44 -0500, Robin Norwood wrote: > "Tom 'spot' Callaway" writes: > > > On Tue, 2007-03-06 at 14:31 +0100, Ralf Corsepius wrote: > > The new spec moves all of: ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, > > and Test::Harness into devel, along with the items that depend on them > > (perlcc, perlivp, h2xs, libnetcfg). I put all of Encode back in base, > > because it seemed like something that might get used by runtime perl > > bits, but if you disagree, I'd like to know (I've not made up my mind > > either way on that one). > > This seems like the right split to me - I'm still a little nervous about > CPAN, but I think after people get used to it, it makes sense, and yum > install perl(CPAN) should get it for them. I wonder if explicitly > providing something called 'cpan' would help - so 'yum install cpan' > would work as well. The FPG mandates perl-CPAN as package name for the module if you would want to split CPAN into a separate package (perl-ExtUtils-MakeMaker also would make sense). However, pay attention to the versions being involved: A perl-CPAN package would be required to carry the version of the CPAN module, not the version of the perl-rpm. Unfortunately choosing different "versions" from inside of one spec isn't easily doable from inside of one spec. Ralf From tcallawa at redhat.com Tue Mar 6 17:03:08 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Tue, 06 Mar 2007 11:03:08 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173200002.25839.137.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173187874.25839.109.camel@mccallum.corsepiu.local> <1173192740.14777.12.camel@localhost.localdomain> <1173200002.25839.137.camel@mccallum.corsepiu.local> Message-ID: <1173200588.14777.42.camel@localhost.localdomain> On Tue, 2007-03-06 at 17:53 +0100, Ralf Corsepius wrote: > On Tue, 2007-03-06 at 11:44 -0500, Robin Norwood wrote: > > "Tom 'spot' Callaway" writes: > > > > > On Tue, 2007-03-06 at 14:31 +0100, Ralf Corsepius wrote: > > > > The new spec moves all of: ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, > > > and Test::Harness into devel, along with the items that depend on them > > > (perlcc, perlivp, h2xs, libnetcfg). I put all of Encode back in base, > > > because it seemed like something that might get used by runtime perl > > > bits, but if you disagree, I'd like to know (I've not made up my mind > > > either way on that one). > > > > This seems like the right split to me - I'm still a little nervous about > > CPAN, but I think after people get used to it, it makes sense, and yum > > install perl(CPAN) should get it for them. I wonder if explicitly > > providing something called 'cpan' would help - so 'yum install cpan' > > would work as well. > The FPG mandates perl-CPAN as package name for the module if you would > want to split CPAN into a separate package (perl-ExtUtils-MakeMaker also > would make sense). > > However, pay attention to the versions being involved: > A perl-CPAN package would be required to carry the version of the CPAN > module, not the version of the perl-rpm. > > Unfortunately choosing different "versions" from inside of one spec > isn't easily doable from inside of one spec. Yeah, I considered doing that, but it would make the spec very ugly. I also considered splitting these items off into their own packages (in fact, I made them into their own packages, to ensure that I got all the bits into perl-devel. The concern about doing this was: A) perl would build its tools against the versions of these modules that we weren't packaging (we'd almost certainly end up with newer modules in dedicated packages). This could lead to bugs. B) It introduced circular dependencies, which we could work around, but I'd like to try to avoid. ~spot From wtogami at redhat.com Wed Mar 7 00:35:45 2007 From: wtogami at redhat.com (Warren Togami) Date: Tue, 06 Mar 2007 19:35:45 -0500 Subject: Final decision on perl-devel? Message-ID: <45EE08E1.6010006@redhat.com> Has the final decision on whether perl-devel will split from perl during F7 been made? I hope that a final decision can be made and announced widely, because currently this issue is causing confusion and doubt among maintainers. Warren Togami wtogami at redhat.com From rc040203 at freenet.de Wed Mar 7 07:14:45 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Mar 2007 08:14:45 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173133807.1407.83.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173133807.1407.83.camel@localhost.localdomain> Message-ID: <1173251685.25839.286.camel@mccallum.corsepiu.local> On Mon, 2007-03-05 at 16:30 -0600, Tom 'spot' Callaway wrote: > Thoughts? Suggestions are welcomed. MUSTFIX: 1. There is a bug in your spec, which rendering the rpms non-installable: ... Requires: perl(ExtUtils::Embed), perl(ExtUtils-MakeMaker) ... Both these Requires are superfluous, furthermore perl(ExtUtils-MakeMaker) is wrong. The perl(ExtUtils-MakeMaker) is the show-stopper. 2. You missed to move enc2xs to devel: /usr/bin/enc2xs depends on /usr/lib/perl5/5.8.8/Encode/Makefile_PL.e2x which indirectly depends on EU::MakeMaker => move enc2xs to *-devel SHOULDFIX: 3. Several man-pages corresponding to tools having been moved from perl to perl-devel are missing from *-devel REMARK: 4. I don't understand why you moved Test::Harness. Besides that Test::Harness probably belongs into *-devel, because it's a Test:: module and therefore probably is not being used at run-time at all, I don't see any pressing requirement to move it now. I'll try to come up with a patch against cvs fixing issues 1-3, throughout today. Ralf From tcallawa at redhat.com Wed Mar 7 07:31:26 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 07 Mar 2007 01:31:26 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173251685.25839.286.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173133807.1407.83.camel@localhost.localdomain> <1173251685.25839.286.camel@mccallum.corsepiu.local> Message-ID: <1173252686.5456.19.camel@localhost.localdomain> On Wed, 2007-03-07 at 08:14 +0100, Ralf Corsepius wrote: > On Mon, 2007-03-05 at 16:30 -0600, Tom 'spot' Callaway wrote: > > > Thoughts? Suggestions are welcomed. > > MUSTFIX: > > 1. There is a bug in your spec, which rendering the rpms > non-installable: > ... > Requires: perl(ExtUtils::Embed), perl(ExtUtils-MakeMaker) Yep. Robin caught that one today too. Sorry bout that. :/ > Both these Requires are superfluous, furthermore > perl(ExtUtils-MakeMaker) is wrong. > > The perl(ExtUtils-MakeMaker) is the show-stopper. > > 2. You missed to move enc2xs to devel: > > /usr/bin/enc2xs depends on /usr/lib/perl5/5.8.8/Encode/Makefile_PL.e2x > which indirectly depends on EU::MakeMaker > => move enc2xs to *-devel OK. > SHOULDFIX: > 3. Several man-pages corresponding to tools having been moved from > perl to perl-devel are missing from *-devel OK. > REMARK: > 4. I don't understand why you moved Test::Harness. > Besides that Test::Harness probably belongs into *-devel, because it's a > Test:: module and therefore probably is not being used at run-time at > all, I don't see any pressing requirement to move it now. I moved it because it seemed an obvious candidate for -devel. Also, when I was separating packages into their own packages, -CPAN needed a much newer Test::Harness. What about the other Test:: items? Do you think they are safe to move to -devel? Or should we just put all of Test:: in base for now? ~spot From rc040203 at freenet.de Wed Mar 7 07:57:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Mar 2007 08:57:54 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173252686.5456.19.camel@localhost.localdomain> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173133807.1407.83.camel@localhost.localdomain> <1173251685.25839.286.camel@mccallum.corsepiu.local> <1173252686.5456.19.camel@localhost.localdomain> Message-ID: <1173254274.25839.296.camel@mccallum.corsepiu.local> On Wed, 2007-03-07 at 01:31 -0600, Tom 'spot' Callaway wrote: > On Wed, 2007-03-07 at 08:14 +0100, Ralf Corsepius wrote: > > On Mon, 2007-03-05 at 16:30 -0600, Tom 'spot' Callaway wrote: > > > > > Thoughts? Suggestions are welcomed. BTW: Your spec lost /usr/bin/cpan > What about the other Test:: items? Do you think they are safe to move to > -devel? Soapbox answer: I would expect moving all Test:: modules to *-devel to be safe, but details need to be looked into before. A quick check (rpm -q --whatrequires) seems to indicate that all base Test::'s but Test::Builder probably will be non-problematic. > Or should we just put all of Test:: in base for now? Can't we gradually move them? ATM, IMO, getting "perl-modules" buildable again and obtaining clarity on how to continue with perl-devel in FC7 should have highest priority. Moving Test:: and further candidates can wait. Ralf From rc040203 at freenet.de Wed Mar 7 11:23:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Mar 2007 12:23:34 +0100 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173251685.25839.286.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173133807.1407.83.camel@localhost.localdomain> <1173251685.25839.286.camel@mccallum.corsepiu.local> Message-ID: <1173266615.25839.303.camel@mccallum.corsepiu.local> On Wed, 2007-03-07 at 08:14 +0100, Ralf Corsepius wrote: > On Mon, 2007-03-05 at 16:30 -0600, Tom 'spot' Callaway wrote: > > > Thoughts? Suggestions are welcomed. > I'll try to come up with a patch against cvs fixing issues 1-3, > throughout today. Below are 2 patches addressing before-mentioned issues and 2 further ones: * Lost /usr/bin/cpan * Test/Harness.pm still was part of perl. This caused perl to depended on perl-devel (i.e. a circular dep). The first patch is against cvs, the second one is against the spec you sent to the list. Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-spec-14.diff Type: text/x-patch Size: 6055 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-spec-14.1.diff Type: text/x-patch Size: 1908 bytes Desc: not available URL: From tcallawa at redhat.com Wed Mar 7 15:28:16 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Wed, 07 Mar 2007 09:28:16 -0600 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173254274.25839.296.camel@mccallum.corsepiu.local> References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173133807.1407.83.camel@localhost.localdomain> <1173251685.25839.286.camel@mccallum.corsepiu.local> <1173252686.5456.19.camel@localhost.localdomain> <1173254274.25839.296.camel@mccallum.corsepiu.local> Message-ID: <1173281297.5456.23.camel@localhost.localdomain> On Wed, 2007-03-07 at 08:57 +0100, Ralf Corsepius wrote: > On Wed, 2007-03-07 at 01:31 -0600, Tom 'spot' Callaway wrote: > > On Wed, 2007-03-07 at 08:14 +0100, Ralf Corsepius wrote: > > > On Mon, 2007-03-05 at 16:30 -0600, Tom 'spot' Callaway wrote: > > > > > > > Thoughts? Suggestions are welcomed. > > BTW: Your spec lost /usr/bin/cpan > > > What about the other Test:: items? Do you think they are safe to move to > > -devel? > Soapbox answer: I would expect moving all Test:: modules to *-devel to > be safe, but details need to be looked into before. > > A quick check (rpm -q --whatrequires) seems to indicate that all base > Test::'s but Test::Builder probably will be non-problematic. > > > Or should we just put all of Test:: in base for now? > Can't we gradually move them? > > ATM, IMO, getting "perl-modules" buildable again and obtaining clarity > on how to continue with perl-devel in FC7 should have highest priority. > > Moving Test:: and further candidates can wait. OK. I'm fine with that. Your patches look good. ~spot From rnorwood at redhat.com Wed Mar 7 17:09:53 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 07 Mar 2007 12:09:53 -0500 Subject: [Bug 230608] missing config.h in latest -14 In-Reply-To: <1173266615.25839.303.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 07 Mar 2007 12:23:34 +0100") References: <200703011938.l21JckAF010053@bugzilla.redhat.com> <1172815768.26830.51.camel@mccallum.corsepiu.local> <45EC3614.3020007@redhat.com> <45EC398F.7090400@city-fan.org> <1173111521.25839.65.camel@mccallum.corsepiu.local> <1173112949.1407.43.camel@localhost.localdomain> <1173114676.1407.53.camel@localhost.localdomain> <1173123209.1407.77.camel@localhost.localdomain> <1173133807.1407.83.camel@localhost.localdomain> <1173251685.25839.286.camel@mccallum.corsepiu.local> <1173266615.25839.303.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Wed, 2007-03-07 at 08:14 +0100, Ralf Corsepius wrote: >> On Mon, 2007-03-05 at 16:30 -0600, Tom 'spot' Callaway wrote: >> >> > Thoughts? Suggestions are welcomed. > >> I'll try to come up with a patch against cvs fixing issues 1-3, >> throughout today. > > Below are 2 patches addressing before-mentioned issues and 2 further > ones: > > * Lost /usr/bin/cpan > * Test/Harness.pm still was part of perl. This caused perl to depended > on perl-devel (i.e. a circular dep). > > The first patch is against cvs, the second one is against the spec you > sent to the list. I'm building a new perl locally with your patches - seems to be going well so far. I'll let you know. -RN > --- perl.spec.14.1 2007-03-07 12:11:55.000000000 +0100 > +++ perl.spec 2007-03-07 12:14:07.000000000 +0100 > @@ -196,7 +196,6 @@ > Summary: Header files for use in perl development > Group: Development/Languages > Requires: perl = %{epoch}:%{version}-%{release} > -Requires: perl(ExtUtils::Embed), perl(ExtUtils-MakeMaker) > > %description devel > This package contains header files and development modules. > @@ -464,10 +463,16 @@ > %ifarch %{multilib_64_archs} > /usr/lib/perl5/ > %endif > +%exclude %{_bindir}/enc2xs > +%exclude %{_mandir}/man1/enc2xs* > %exclude %{_bindir}/h2xs > +%exclude %{_mandir}/man1/h2xs* > %exclude %{_bindir}/libnetcfg > +%exclude %{_mandir}/man1/libnetcfg* > %exclude %{_bindir}/perlcc > +%exclude %{_mandir}/man1/perlcc* > %exclude %{_bindir}/perlivp > +%exclude %{_mandir}/man1/perlivp* > %exclude %{_bindir}/suidperl > %exclude %{_bindir}/sperl%{version} > %exclude %{_libdir}/perl5/%{version}/%{perl_archname}/CORE/*.h > @@ -512,18 +517,25 @@ > %exclude %{_mandir}/man3/ExtUtils::testlib.3* > # Test::Harness > %exclude %{_bindir}/prove > -%exclude /usr/lib/perl5/%{version}/Test/Harness/ > +%exclude /usr/lib/perl5/%{version}/Test/Harness* > %exclude %{_mandir}/man1/prove.1* > %exclude %{_mandir}/man3/Test::Harness* > > %files devel > %defattr(-,root,root,-) > +%{_bindir}/enc2xs > +%{_mandir}/man1/enc2xs* > %{_bindir}/h2xs > +%{_mandir}/man1/h2xs* > %{_bindir}/libnetcfg > +%{_mandir}/man1/libnetcfg* > %{_bindir}/perlcc > +%{_mandir}/man1/perlcc* > %{_bindir}/perlivp > +%{_mandir}/man1/perlivp* > %{_libdir}/perl5/%{version}/%{perl_archname}/CORE/*.h > #CPAN > +%{_bindir}/cpan > /usr/lib/perl5/%{version}/CPAN/ > /usr/lib/perl5/%{version}/CPAN.pm > %{_mandir}/man1/cpan.1* > @@ -563,7 +575,7 @@ > %{_mandir}/man3/ExtUtils::testlib.3* > # Test::Harness > %{_bindir}/prove > -/usr/lib/perl5/%{version}/Test/Harness/ > +/usr/lib/perl5/%{version}/Test/Harness* > %{_mandir}/man1/prove.1* > %{_mandir}/man3/Test::Harness* -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rnorwood at redhat.com Wed Mar 7 17:20:49 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 07 Mar 2007 12:20:49 -0500 Subject: Final decision on perl-devel? In-Reply-To: <45EE08E1.6010006@redhat.com> (Warren Togami's message of "Tue, 06 Mar 2007 19:35:45 -0500") References: <45EE08E1.6010006@redhat.com> Message-ID: Warren Togami writes: > Has the final decision on whether perl-devel will split from perl > during F7 been made? > > I hope that a final decision can be made and announced widely, because > currently this issue is causing confusion and doubt among maintainers. I think we are going with perl/perl-devel split. Spot, Rafael, and others are working on getting things into a state where we can build another release. There don't seem to be any showstoppers at this point. I'll make an announcement when we know more. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rc040203 at freenet.de Wed Mar 7 17:38:15 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 07 Mar 2007 18:38:15 +0100 Subject: Final decision on perl-devel? In-Reply-To: References: <45EE08E1.6010006@redhat.com> Message-ID: <1173289096.25839.334.camel@mccallum.corsepiu.local> On Wed, 2007-03-07 at 12:20 -0500, Robin Norwood wrote: > Warren Togami writes: > > > Has the final decision on whether perl-devel will split from perl > > during F7 been made? > > > > I hope that a final decision can be made and announced widely, because > > currently this issue is causing confusion and doubt among maintainers. > > I think we are going with perl/perl-devel split. Spot, Rafael, and > others are working on getting things into a state where we can build > another release. There don't seem to be any showstoppers at this > point. I'll make an announcement when we know more. I noticed a further problems: On FC6 with a locally build perl*-14.1 (including my most recent patches) in a local repo in addition to the FC's core+extras, yum install 'perl(ExtUtils::MakeMaker)' fails: # rpm -q --whatprovides 'perl(ExtUtils::MakeMaker)' no package provides perl(ExtUtils::MakeMaker) # yum install 'perl(ExtUtils::MakeMaker)' ... Nothing to do # repoquery --whatprovides 'perl(ExtUtils::MakeMaker)' perl-4:5.8.8-10.i386 perl-devel-4:5.8.8-14.1.i386 # yum install perl-devel ... Installed: perl-devel.i386 4:5.8.8-14.1 Seems to me as if yum can't properly handle this split. May-be, it can't handle resolving a property (perl(ExtUtils::MakeMaker)) being provided by different packages perl rsp. perl-devel. Ralf From rnorwood at redhat.com Wed Mar 7 18:10:11 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 07 Mar 2007 13:10:11 -0500 Subject: Final decision on perl-devel? In-Reply-To: <1173289096.25839.334.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Wed, 07 Mar 2007 18:38:15 +0100") References: <45EE08E1.6010006@redhat.com> <1173289096.25839.334.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Wed, 2007-03-07 at 12:20 -0500, Robin Norwood wrote: [...] > I noticed a further problems: > > On FC6 with a locally build perl*-14.1 (including my most recent > patches) in a local repo in addition to the FC's core+extras, > > yum install 'perl(ExtUtils::MakeMaker)' > fails: > > # rpm -q --whatprovides 'perl(ExtUtils::MakeMaker)' > no package provides perl(ExtUtils::MakeMaker) > > # yum install 'perl(ExtUtils::MakeMaker)' > ... > Nothing to do > > # repoquery --whatprovides 'perl(ExtUtils::MakeMaker)' > perl-4:5.8.8-10.i386 > perl-devel-4:5.8.8-14.1.i386 > > # yum install perl-devel > ... > Installed: perl-devel.i386 4:5.8.8-14.1 > > > Seems to me as if yum can't properly handle this split. > > May-be, it can't handle resolving a property (perl(ExtUtils::MakeMaker)) > being provided by different packages perl rsp. perl-devel. Yeah, maybe we need to tweak the dependencies here. I'll poke around and see if I can figure it out, and maybe ask the Yum guys for advice. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From bugzilla at redhat.com Wed Mar 7 20:50:16 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 7 Mar 2007 15:50:16 -0500 Subject: [Bug 231357] New: ParseConfig is an undefined subroutine Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231357 Summary: ParseConfig is an undefined subroutine Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-Config-General AssignedTo: ville.skytta at iki.fi ReportedBy: emmanuel.seyman at club-internet.fr QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com Description of problem: When using the Config::Genral module, ParseConfig() cannot be used and the script dies with the message : Undefined subroutine &main::ParseConfig called at pc line 2. Version-Release number of selected component (if applicable): 2.32-1.fc6 (Fedora 6 with all updates) How reproducible: Always Steps to Reproduce: 1. Create an empty rcfile 2. Run the command : perl -MConfig::General -e 'ParseConfig("rcfile")' Actual results: Undefined subroutine &main::ParseConfig called at -e line 1. Expected results: Perl should run the command and return to the shell prompt -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 7 22:38:50 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 7 Mar 2007 17:38:50 -0500 Subject: [Bug 231357] ParseConfig is an undefined subroutine In-Reply-To: Message-ID: <200703072238.l27Mco6F005053@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: ParseConfig is an undefined subroutine https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231357 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG ------- Additional Comments From ville.skytta at iki.fi 2007-03-07 17:38 EST ------- >From upstream ChangeLog: o the functions ParseConfig SaveConfig SaveConfigString must now imported implicitly. This might break existing code, but is easily to fix. So with 2.32, one needs to do something like "use Config::General qw(ParseConfig) ; ParseConfig(...)", or perl -MConfig::General=ParseConfig -e 'ParseConfig(...)'. In retrospect, maybe it was a mistake to push this update to older releases than the current development repository, but it's in now and like the changelog says, it's an easy one to fix - sorry if it caused problems. FWIW, I looked through the dependent Fedora packages and didn't see anything affected before pushing the update. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From ralf.corsepius at rtems.org Wed Mar 7 17:34:49 2007 From: ralf.corsepius at rtems.org (Ralf Corsepius) Date: Wed, 07 Mar 2007 18:34:49 +0100 Subject: Final decision on perl-devel? In-Reply-To: References: <45EE08E1.6010006@redhat.com> Message-ID: <1173288889.25839.332.camel@mccallum.corsepiu.local> On Wed, 2007-03-07 at 12:20 -0500, Robin Norwood wrote: > Warren Togami writes: > > > Has the final decision on whether perl-devel will split from perl > > during F7 been made? > > > > I hope that a final decision can be made and announced widely, because > > currently this issue is causing confusion and doubt among maintainers. > > I think we are going with perl/perl-devel split. Spot, Rafael, and > others are working on getting things into a state where we can build > another release. There don't seem to be any showstoppers at this > point. I'll make an announcement when we know more. I noticed a further problems: On FC6 with a locally build perl*-14.1 (including my most recent patches) in a local repo in addition to the FC's core+extras, yum install 'perl(ExtUtils::MakeMaker)' fails: # rpm -q --whatprovides 'perl(ExtUtils::MakeMaker)' no package provides perl(ExtUtils::MakeMaker) # yum install 'perl(ExtUtils::MakeMaker)' ... Nothing to do # repoquery --whatprovides 'perl(ExtUtils::MakeMaker)' perl-4:5.8.8-10.i386 perl-devel-4:5.8.8-14.1.i386 # yum install perl-devel ... Installed: perl-devel.i386 4:5.8.8-14.1 Seems to me as if yum can't properly handle this split. May-be, it can't handle resolving a property (perl(ExtUtils::MakeMaker)) being provided by different packages perl rsp. perl-devel). Ralf From rnorwood at redhat.com Thu Mar 8 22:22:57 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 08 Mar 2007 17:22:57 -0500 Subject: Final decision on perl-devel? In-Reply-To: (Robin Norwood's message of "Wed, 07 Mar 2007 13:10:11 -0500") References: <45EE08E1.6010006@redhat.com> <1173289096.25839.334.camel@mccallum.corsepiu.local> Message-ID: Robin Norwood writes: > Ralf Corsepius writes: > >> On Wed, 2007-03-07 at 12:20 -0500, Robin Norwood wrote: > > [...] > >> I noticed a further problems: >> >> On FC6 with a locally build perl*-14.1 (including my most recent >> patches) in a local repo in addition to the FC's core+extras, >> >> yum install 'perl(ExtUtils::MakeMaker)' >> fails: >> >> # rpm -q --whatprovides 'perl(ExtUtils::MakeMaker)' >> no package provides perl(ExtUtils::MakeMaker) >> >> # yum install 'perl(ExtUtils::MakeMaker)' >> ... >> Nothing to do >> >> # repoquery --whatprovides 'perl(ExtUtils::MakeMaker)' >> perl-4:5.8.8-10.i386 >> perl-devel-4:5.8.8-14.1.i386 >> >> # yum install perl-devel >> ... >> Installed: perl-devel.i386 4:5.8.8-14.1 >> >> >> Seems to me as if yum can't properly handle this split. >> >> May-be, it can't handle resolving a property (perl(ExtUtils::MakeMaker)) >> being provided by different packages perl rsp. perl-devel. > > Yeah, maybe we need to tweak the dependencies here. I'll poke around > and see if I can figure it out, and maybe ask the Yum guys for advice. It looks like you unearthed a bug in yum. Reproduced and filed a bug here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 I don't think this should be a blocker for the perl/perl-devel split, since: o It's a yum bug. o perl-devel is still installable with 'yum install perl-devel' o In many cases (if the user has something installed that depends on something that only perl-devel will provide), the user will get perl-devel anyway. What do you think? -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From steve at silug.org Thu Mar 8 22:47:35 2007 From: steve at silug.org (Steven Pritchard) Date: Thu, 8 Mar 2007 16:47:35 -0600 Subject: Pre-review: parrot and pugs In-Reply-To: <20070306012417.GA21218@osiris.silug.org> References: <20060627203020.GA31510@osiris.silug.org> <20070306012417.GA21218@osiris.silug.org> Message-ID: <20070308224735.GA21225@osiris.silug.org> On Mon, Mar 05, 2007 at 07:24:17PM -0600, Steven Pritchard wrote: > http://ftp.kspei.com/pub/steve/rpms/perl-Perl6-Pugs-6.2.13-1.src.rpm > http://ftp.kspei.com/pub/steve/rpms/perl-Perl6-Pugs/perl-Perl6-Pugs.spec I am now making a mental note to copy things to the ftp server *before* mentioning them on a public list... It's really there now, if anyone is interested. :-) Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From rc040203 at freenet.de Fri Mar 9 03:07:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Mar 2007 04:07:12 +0100 Subject: Final decision on perl-devel? In-Reply-To: References: <45EE08E1.6010006@redhat.com> <1173289096.25839.334.camel@mccallum.corsepiu.local> Message-ID: <1173409632.25839.369.camel@mccallum.corsepiu.local> On Thu, 2007-03-08 at 17:22 -0500, Robin Norwood wrote: > Robin Norwood writes: > > > Ralf Corsepius writes: > > > >> On Wed, 2007-03-07 at 12:20 -0500, Robin Norwood wrote: > > > > [...] > > > >> I noticed a further problems: > >> > >> On FC6 with a locally build perl*-14.1 (including my most recent > >> patches) in a local repo in addition to the FC's core+extras, > >> > >> yum install 'perl(ExtUtils::MakeMaker)' > >> fails: > >> > >> # rpm -q --whatprovides 'perl(ExtUtils::MakeMaker)' > >> no package provides perl(ExtUtils::MakeMaker) > >> > >> # yum install 'perl(ExtUtils::MakeMaker)' > >> ... > >> Nothing to do > >> > >> # repoquery --whatprovides 'perl(ExtUtils::MakeMaker)' > >> perl-4:5.8.8-10.i386 > >> perl-devel-4:5.8.8-14.1.i386 > >> > >> # yum install perl-devel > >> ... > >> Installed: perl-devel.i386 4:5.8.8-14.1 > >> > >> > >> Seems to me as if yum can't properly handle this split. > >> > >> May-be, it can't handle resolving a property (perl(ExtUtils::MakeMaker)) > >> being provided by different packages perl rsp. perl-devel. > > > > Yeah, maybe we need to tweak the dependencies here. I'll poke around > > and see if I can figure it out, and maybe ask the Yum guys for advice. > > It looks like you unearthed a bug in yum. Reproduced and filed a bug > here: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 > > I don't think this should be a blocker for the perl/perl-devel split, I am not sure about this, because ... > since: > > o It's a yum bug. > o perl-devel is still installable with 'yum install perl-devel' > o In many cases (if the user has something installed that depends on > something that only perl-devel will provide), the user will get > perl-devel anyway. > > What do you think? > .. this issue renders using BuildRequires: perl(ExtUtils::MakeMaker) (The "correct" BuildRequires for MakeMaker based perl-modules) non-functional and (bogusly) forces packagers to resort to using BuildRequires: perl-devel or BuildRequires: perl(ExtUtils::MakeMaker) perl-devel instead. Background: I have another patch to the perl package pending, which physically separates ExtUtils::MakeMaker, CPAN, Test::Simple and Test::Harness from "perl-devel". It resolves the issue of some packages (e.g. mod_perl) to directly depend on perl-devel at run-time. Ralf From rc040203 at freenet.de Fri Mar 9 05:15:56 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 09 Mar 2007 06:15:56 +0100 Subject: Splitting out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker Message-ID: <1173417356.25839.400.camel@mccallum.corsepiu.local> Hi, Below is before-mentioned patch to perl.spec to split out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker from perl-devel, I'd like to propose to be applied to perl.spec. Advantages: * The split-out allows such modules to be "alternatively supplied" from separate/independent source packages. * Improved fine-grained run-time deps. Disadvantages: * The split-out reveals BuildRequire-ment "sloppiness"es in current perl-dist packages (So far, deps on "core" modules had been frowed upon). Implementation notes: * The perl- packages apply an epoch = 0 and a version corresponding to their perl-dists, but apply the release number of the main-perl package. * To be able to implement this (Building several packages with different versions and epochs from one single spec), one can't use %{version} and %{epoch} because rpmbuild overrides them depending on the context inside of a spec-file. One has to resort to hard-code or %define them. I chose to use a %define for the main package's version. * I do not expect this spec to be free of bugs and oversights ;) Feedback welcome. Ralf PS.: The patch below is against CVS and comprises all of Spot's an my changes so far. -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-spec.14.6.diff Type: text/x-patch Size: 14585 bytes Desc: not available URL: From rnorwood at redhat.com Fri Mar 9 16:17:45 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 09 Mar 2007 11:17:45 -0500 Subject: Final decision on perl-devel? In-Reply-To: <1173409632.25839.369.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 09 Mar 2007 04:07:12 +0100") References: <45EE08E1.6010006@redhat.com> <1173289096.25839.334.camel@mccallum.corsepiu.local> <1173409632.25839.369.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: [...] >> It looks like you unearthed a bug in yum. Reproduced and filed a bug >> here: >> >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 >> >> I don't think this should be a blocker for the perl/perl-devel split, > I am not sure about this, because ... > >> since: >> >> o It's a yum bug. >> o perl-devel is still installable with 'yum install perl-devel' >> o In many cases (if the user has something installed that depends on >> something that only perl-devel will provide), the user will get >> perl-devel anyway. >> >> What do you think? >> > > .. this issue renders using > > BuildRequires: perl(ExtUtils::MakeMaker) > (The "correct" BuildRequires for MakeMaker based perl-modules) > > non-functional and (bogusly) forces packagers to resort to using > BuildRequires: perl-devel > or > BuildRequires: perl(ExtUtils::MakeMaker) perl-devel Ok. Seth seems to think he can get that bug fixed for us 'soon', so, assuming it does get fixed soon, I don't think that will be an issue for long. How about I run a build that has a 'Requires: perl-devel' for perl, and remove that for the next one? I just don't want to leave people broken over the weekend. If for some reason Seth can't get this bug fixed for us in F7 time frame, we may end up needing to leave that Requires in for F7, but of course I'd rather not do that. > instead. > > Background: I have another patch to the perl package pending, which > physically separates ExtUtils::MakeMaker, CPAN, Test::Simple and > Test::Harness from "perl-devel". It resolves the issue of some packages > (e.g. mod_perl) to directly depend on perl-devel at run-time. Not sure if I follow - do you mean separates into their own packages, or puts them back into 'perl'? Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rnorwood at redhat.com Fri Mar 9 16:28:35 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 09 Mar 2007 11:28:35 -0500 Subject: Splitting out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker In-Reply-To: <1173417356.25839.400.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 09 Mar 2007 06:15:56 +0100") References: <1173417356.25839.400.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > Hi, > > Below is before-mentioned patch to perl.spec to split out > CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker > from > perl-devel, I'd like to propose to be applied to perl.spec. > > Advantages: > * The split-out allows such modules to be "alternatively supplied" from > separate/independent source packages. > * Improved fine-grained run-time deps. > > Disadvantages: > * The split-out reveals BuildRequire-ment "sloppiness"es in current > perl-dist packages (So far, deps on "core" modules had been frowed > upon). > > > Implementation notes: > > * The perl- packages apply an epoch = 0 and a version > corresponding to their perl-dists, but apply the release number of the > main-perl package. > > * To be able to implement this (Building several packages with different > versions and epochs from one single spec), one can't use %{version} and > %{epoch} because rpmbuild overrides them depending on the context inside > of a spec-file. > One has to resort to hard-code or %define them. I chose to use a %define > for the main package's version. > > * I do not expect this spec to be free of bugs and oversights ;) > > Feedback welcome. > > Ralf > > PS.: The patch below is against CVS and comprises all of Spot's an my > changes so far. Looks pretty good to me at first glace - I'm not totally convinced we want to do this right now though...I'd like to get some more discussion on the list first. We'll probably want to re-enable 'make test' at some point, too. ;-) Since this isn't quite done yet, how about: o I build a perl with all the changes except this one, including a 'Requires: perl-devel' for the main perl package. o We let people chime in on your changes over the weekend. o If people like these changes, we'll get them into rawhide next week. Thanks, -RN > Index: perl.spec > =================================================================== > RCS file: /cvs/dist/devel/perl/perl.spec,v > retrieving revision 1.108 > diff -u -r1.108 perl.spec > --- perl.spec 28 Feb 2007 15:34:50 -0000 1.108 > +++ perl.spec 9 Mar 2007 04:52:42 -0000 > @@ -8,6 +8,8 @@ > %define new_perl_flags LD_PRELOAD=/%{new_arch_lib}/CORE/libperl.so LD_LIBRARY_PATH=%{new_arch_lib}/CORE PERL5LIB=%{new_perl_lib}:%{comp_perl_lib} > %define new_perl %{new_perl_flags} $RPM_BUILD_ROOT/%{_bindir}/perl > > +%define perl_vers 5.8.8 > + > # Use this for SUPER PERL DEBUGGING MODE. > %{?!perl_debugging: %define perl_debugging 0} > %if %{perl_debugging} > @@ -17,13 +19,13 @@ > > Name: perl > Version: 5.8.8 > -Release: 14%{?dist} > +Release: 14%{?dist}.1.6 > Epoch: 4 > Summary: The Perl programming language > Group: Development/Languages > License: Artistic or GPL > Url: http://www.perl.org/ > -Source0: http://www.cpan.org/authors/id/N/NW/NWCLARK/%{name}-%{version}.tar.bz2 > +Source0: http://www.cpan.org/authors/id/N/NW/NWCLARK/%{name}-%{perl_vers}.tar.bz2 > Source11: filter-depends.sh > Source12: perl-5.8.0-libnet.cfg > # Specific to Fedora/RHEL > @@ -107,7 +109,7 @@ > Patch38: perl-5.8.8-bz199736.patch > # XXX: Fixme - Finish patch. > Patch39: perl-5.8.8-bz204679.patch > -BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) > +BuildRoot: %{_tmppath}/%{name}-%{perl_vers}-%{release}-root-%(%{__id_u} -n) > BuildRequires: tcsh, dos2unix, man, groff > BuildRequires: gdbm-devel, db4-devel > > @@ -195,21 +197,58 @@ > %package devel > Summary: Header files for use in perl development > Group: Development/Languages > -Requires: perl = %{epoch}:%{version}-%{release} > +Requires: perl = %{epoch}:%{perl_vers}-%{release} > > %description devel > -This package contains header files from core perl components. > -Some packages may need these header files in order to build. > +This package contains header files and development modules. > +Most perl packages will need to install perl-devel to build. > > %package suidperl > Summary: Suidperl, for use with setuid perl scripts > Group: Development/Languages > -Requires: perl = %{epoch}:%{version}-%{release} > +Requires: perl = %{epoch}:%{perl_vers}-%{release} > > %description suidperl > Suidperl is a setuid binary copy of perl that allows for (hopefully) > more secure running of setuid perl scripts. > > +%package CPAN > +Summary: Query, download and build perl modules from CPAN sites > +Group: Development/Languages > +Epoch: 0 > +Version: 1.76_02 > + > +%description CPAN > +Query, download and build perl modules from CPAN sites. > + > +%package ExtUtils-MakeMaker > +Summary: Create a module Makefile > +Group: Development/Languages > +Epoch: 0 > +Version: 6.30 > +Requires: perl-devel > + > +%description ExtUtils-MakeMaker > +Create a module Makefile. > + > +%package Test-Harness > +Summary: Run Perl standard test scripts with statistics > +Group: Development/Languages > +Epoch: 0 > +Version: 2.56 > + > +%description Test-Harness > +Run Perl standard test scripts with statistics. > + > +%package Test-Simple > +Summary: Basic utilities for writing tests > +Group: Development/Languages > +Epoch: 0 > +Version: 0.62 > + > +%description Test-Simple > +Basic utilities for writing tests. > + > %prep > %setup -q > %patch1 -p1 > @@ -291,7 +330,7 @@ > sed -e '/^perl(bytes)$/d' |\ > sed -e '/^perl(utf8)$/d' > EOF > -%define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov > +%define __perl_provides %{_builddir}/%{name}-%{perl_vers}/%{name}-prov > chmod +x %{__perl_provides} > > > @@ -303,7 +342,7 @@ > # similar reasons. > > sh Configure -des -Doptimize="$RPM_OPT_FLAGS" \ > - -Dversion=%{version} \ > + -Dversion=%{perl_vers} \ > -Dmyhostname=localhost \ > -Dperladmin=root at localhost \ > -Dcc='%{__cc}' \ > @@ -312,12 +351,12 @@ > -Dprefix=%{_prefix} \ > %ifarch %{multilib_64_archs} > -Dlibpth="/usr/local/lib64 /lib64 /usr/lib64" \ > - -Dprivlib="/usr/lib/perl5/%{version}" \ > - -Dsitelib="/usr/lib/perl5/site_perl/%{version}" \ > - -Dvendorlib="/usr/lib/perl5/vendor_perl/%{version}" \ > - -Darchlib="%{_libdir}/perl5/%{version}/%{perl_archname}" \ > - -Dsitearch="%{_libdir}/perl5/site_perl/%{version}/%{perl_archname}" \ > - -Dvendorarch="%{_libdir}/perl5/vendor_perl/%{version}/%{perl_archname}" \ > + -Dprivlib="/usr/lib/perl5/%{perl_vers}" \ > + -Dsitelib="/usr/lib/perl5/site_perl/%{perl_vers}" \ > + -Dvendorlib="/usr/lib/perl5/vendor_perl/%{perl_vers}" \ > + -Darchlib="%{_libdir}/perl5/%{perl_vers}/%{perl_archname}" \ > + -Dsitearch="%{_libdir}/perl5/site_perl/%{perl_vers}/%{perl_archname}" \ > + -Dvendorarch="%{_libdir}/perl5/vendor_perl/%{perl_vers}/%{perl_archname}" \ > %endif > -Darchname=%{_arch}-%{_os} \ > %ifarch sparc > @@ -356,16 +395,15 @@ > make install DESTDIR=$RPM_BUILD_ROOT > > %ifarch %{multilib_64_archs} > -mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/%{version} > -mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/site_perl/%{version} > -mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/vendor_perl/%{version} > +mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_vers} > +mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/site_perl/%{perl_vers} > +mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/vendor_perl/%{perl_vers} > %endif > > %ifarch %{multilib_64_archs} > -mkdir -p -m 755 ${RPM_BUILD_ROOT}/usr/lib64/perl5/vendor_perl/%{version}/%{_arch}-%{_os} > +mkdir -p -m 755 ${RPM_BUILD_ROOT}/usr/lib64/perl5/vendor_perl/%{perl_vers}/%{_arch}-%{_os} > %endif > > - > # > # Compatibility directories > # > @@ -374,7 +412,7 @@ > mkdir -pm 755 $i/%{perl_archname}/CORE > mkdir -pm 755 $i/%{perl_archname}/auto > pushd $i/%{perl_archname}/CORE > - ln -s ../../../%{version}/%{perl_archname}/CORE/libperl.so libperl.so > + ln -s ../../../%{perl_vers}/%{perl_archname}/CORE/libperl.so libperl.so > popd > done > popd > @@ -384,7 +422,7 @@ > for i in asm/termios.h syscall.h syslimits.h syslog.h sys/ioctl.h sys/socket.h sys/time.h wait.h > do > %{new_perl} $RPM_BUILD_ROOT/%{_bindir}/h2ph -a \ > - -d $RPM_BUILD_ROOT%{_libdir}/perl5/%{version}/%{perl_archname} $i || /bin/true > + -d $RPM_BUILD_ROOT%{_libdir}/perl5/%{perl_vers}/%{perl_archname} $i || /bin/true > done > > > @@ -398,7 +436,7 @@ > mkdir -p $RPM_BUILD_ROOT/$dir > done > > -for i in %{version} %{perlmodcompat} ; do > +for i in %{perl_vers} %{perlmodcompat} ; do > mkdir -pm 755 $RPM_BUILD_ROOT%{_libdir}/perl5/site_perl/$i/%{perl_archname}/auto > mkdir -pm 755 $RPM_BUILD_ROOT%{_libdir}/perl5/vendor_perl/$i/%{perl_archname}/auto > done > @@ -407,8 +445,8 @@ > # > # libnet configuration file > # > -mkdir -p -m 755 $RPM_BUILD_ROOT/%{_libdir}/perl5/%{version}/Net > -install -p -m 644 %{SOURCE12} $RPM_BUILD_ROOT/%{_libdir}/perl5/%{version}/Net/libnet.cfg > +mkdir -p -m 755 $RPM_BUILD_ROOT/%{_libdir}/perl5/%{perl_vers}/Net > +install -p -m 644 %{SOURCE12} $RPM_BUILD_ROOT/%{_libdir}/perl5/%{perl_vers}/Net/libnet.cfg > > # > # Core modules removal > @@ -418,7 +456,7 @@ > find $RPM_BUILD_ROOT -type f -name '*.bs' -a -empty -exec rm -f {} ';' > > # Cleanup binary paths and make cgi files executable > -pushd $RPM_BUILD_ROOT/usr/lib/perl5/%{version}/CGI/eg/ > +pushd $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_vers}/CGI/eg/ > for i in *.cgi make_links.pl RunMeFirst ; do > sed -i 's|/usr/local/bin/perl|/usr/bin/perl|g' $i > chmod +x $i > @@ -426,11 +464,11 @@ > popd > > # miniperl? As an interpreter? How odd. > -sed -i 's|./miniperl|/usr/bin/perl|' $RPM_BUILD_ROOT/usr/lib/perl5/%{version}/ExtUtils/xsubpp > -chmod +x $RPM_BUILD_ROOT/usr/lib/perl5/%{version}/ExtUtils/xsubpp > +sed -i 's|./miniperl|/usr/bin/perl|' $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_vers}/ExtUtils/xsubpp > +chmod +x $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_vers}/ExtUtils/xsubpp > > # Don't need the .packlist > -rm -f $RPM_BUILD_ROOT%{_libdir}/perl5/%{version}/%{perl_archname}/.packlist > +rm -f $RPM_BUILD_ROOT%{_libdir}/perl5/%{perl_vers}/%{perl_archname}/.packlist > > # Fix some manpages to be UTF-8 > pushd $RPM_BUILD_ROOT%{_mandir}/man1/ > @@ -451,7 +489,8 @@ > rm -rf $RPM_BUILD_ROOT > > %check > -make test > +# make test > + > > %files > %defattr(-,root,root,-) > @@ -463,22 +502,162 @@ > %ifarch %{multilib_64_archs} > /usr/lib/perl5/ > %endif > +%exclude %{_bindir}/enc2xs > +%exclude %{_mandir}/man1/enc2xs* > +%exclude %{_bindir}/h2xs > +%exclude %{_mandir}/man1/h2xs* > +%exclude %{_bindir}/libnetcfg > +%exclude %{_mandir}/man1/libnetcfg* > +%exclude %{_bindir}/perlcc > +%exclude %{_mandir}/man1/perlcc* > +%exclude %{_bindir}/perlivp > +%exclude %{_mandir}/man1/perlivp* > %exclude %{_bindir}/suidperl > -%exclude %{_bindir}/sperl%{version} > -%exclude %{_libdir}/perl5/%{version}/%{perl_archname}/CORE/*.h > -%exclude /usr/lib/perl5/%{version}/Encode/*.h > +%exclude %{_bindir}/sperl%{perl_vers} > +%exclude %{_libdir}/perl5/%{perl_vers}/%{perl_archname}/CORE/*.h > +# CPAN > +%exclude %{_bindir}/cpan > +%exclude /usr/lib/perl5/%{perl_vers}/CPAN/ > +%exclude /usr/lib/perl5/%{perl_vers}/CPAN.pm > +%exclude %{_mandir}/man1/cpan.1* > +%exclude %{_mandir}/man3/CPAN* > +# ExtUtils-Embed > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Embed.pm > +%exclude %{_mandir}/man3/ExtUtils::Embed* > +# ExtUtils-MakeMaker > +%exclude %{_bindir}/instmodsh > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Command/MM.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Install.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Installed.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Liblist/ > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Liblist.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/MakeMaker/ > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/MakeMaker.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/MANIFEST.SKIP > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/MM*.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/MY.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Manifest.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Mkbootstrap.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Mksymlists.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/Packlist.pm > +%exclude /usr/lib/perl5/%{perl_vers}/ExtUtils/testlib.pm > +%exclude %{_libdir}/perl5/%{perl_vers}/ExtUtils/NOTES > +%exclude %{_libdir}/perl5/%{perl_vers}/ExtUtils/PATCHING > +%exclude %{_mandir}/man1/instmodsh.1* > +%exclude %{_mandir}/man3/ExtUtils::Command::MM* > +%exclude %{_mandir}/man3/ExtUtils::Install.3* > +%exclude %{_mandir}/man3/ExtUtils::Installed.3* > +%exclude %{_mandir}/man3/ExtUtils::Liblist.3* > +%exclude %{_mandir}/man3/ExtUtils::MM* > +%exclude %{_mandir}/man3/ExtUtils::MY.3* > +%exclude %{_mandir}/man3/ExtUtils::MakeMaker* > +%exclude %{_mandir}/man3/ExtUtils::Manifest.3* > +%exclude %{_mandir}/man3/ExtUtils::Mkbootstrap.3* > +%exclude %{_mandir}/man3/ExtUtils::Mksymlists.3* > +%exclude %{_mandir}/man3/ExtUtils::Packlist.3* > +%exclude %{_mandir}/man3/ExtUtils::testlib.3* > +# Test::Harness > +%exclude %{_bindir}/prove > +%exclude /usr/lib/perl5/%{perl_vers}/Test/Harness* > +%exclude %{_mandir}/man1/prove.1* > +%exclude %{_mandir}/man3/Test::Harness* > +# Test::Simple > +%exclude /usr/lib/perl5/%{perl_vers}/Test/More* > +%exclude /usr/lib/perl5/%{perl_vers}/Test/Builder* > +%exclude /usr/lib/perl5/%{perl_vers}/Test/Simple* > +%exclude /usr/lib/perl5/%{perl_vers}/Test/Tutorial* > +%exclude %{_mandir}/man3/Test::More* > +%exclude %{_mandir}/man3/Test::Builder* > +%exclude %{_mandir}/man3/Test::Simple* > +%exclude %{_mandir}/man3/Test::Tutorial* > > %files devel > %defattr(-,root,root,-) > -%{_libdir}/perl5/%{version}/%{perl_archname}/CORE/*.h > -/usr/lib/perl5/%{version}/Encode/*.h > +%{_bindir}/enc2xs > +%{_mandir}/man1/enc2xs* > +%{_bindir}/h2xs > +%{_mandir}/man1/h2xs* > +%{_bindir}/libnetcfg > +%{_mandir}/man1/libnetcfg* > +%{_bindir}/perlcc > +%{_mandir}/man1/perlcc* > +%{_bindir}/perlivp > +%{_mandir}/man1/perlivp* > +%{_libdir}/perl5/%{perl_vers}/%{perl_archname}/CORE/*.h > +# ExtUtils-Embed > +/usr/lib/perl5/%{perl_vers}/ExtUtils/Embed.pm > +%{_mandir}/man3/ExtUtils::Embed* > + > +%files Test-Harness > +# Test::Harness > +%{_bindir}/prove > +/usr/lib/perl5/%{perl_vers}/Test/Harness* > +%{_mandir}/man1/prove.1* > +%{_mandir}/man3/Test::Harness* > + > +%files CPAN > +#CPAN > +%{_bindir}/cpan > +/usr/lib/perl5/%{perl_vers}/CPAN/ > +/usr/lib/perl5/%{perl_vers}/CPAN.pm > +%{_mandir}/man1/cpan.1* > +%{_mandir}/man3/CPAN* > + > +%files ExtUtils-MakeMaker > +# ExtUtils-MakeMaker > +%{_bindir}/instmodsh > +/usr/lib/perl5/%{perl_vers}/ExtUtils/Command/MM.pm > +/usr/lib/perl5/%{perl_vers}/ExtUtils/Install.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Installed.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Liblist/ > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Liblist.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/MakeMaker/ > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/MakeMaker.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/MANIFEST.SKIP > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/MM*.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/MY.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Manifest.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Mkbootstrap.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Mksymlists.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/Packlist.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/testlib.pm > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/NOTES > +%{_libdir}/perl5/%{perl_vers}/ExtUtils/PATCHING > +%{_mandir}/man1/instmodsh.1* > +%{_mandir}/man3/ExtUtils::Command::MM* > +%{_mandir}/man3/ExtUtils::Install.3* > +%{_mandir}/man3/ExtUtils::Installed.3* > +%{_mandir}/man3/ExtUtils::Liblist.3* > +%{_mandir}/man3/ExtUtils::MM* > +%{_mandir}/man3/ExtUtils::MY.3* > +%{_mandir}/man3/ExtUtils::MakeMaker* > +%{_mandir}/man3/ExtUtils::Manifest.3* > +%{_mandir}/man3/ExtUtils::Mkbootstrap.3* > +%{_mandir}/man3/ExtUtils::Mksymlists.3* > +%{_mandir}/man3/ExtUtils::Packlist.3* > +%{_mandir}/man3/ExtUtils::testlib.3* > + > +%files Test-Simple > +# Test::Simple > +/usr/lib/perl5/%{perl_vers}/Test/More* > +/usr/lib/perl5/%{perl_vers}/Test/Builder* > +/usr/lib/perl5/%{perl_vers}/Test/Simple* > +/usr/lib/perl5/%{perl_vers}/Test/Tutorial* > +%{_mandir}/man3/Test::More* > +%{_mandir}/man3/Test::Builder* > +%{_mandir}/man3/Test::Simple* > +%{_mandir}/man3/Test::Tutorial* > > %files suidperl > %defattr(-,root,root,-) > %{_bindir}/suidperl > -%{_bindir}/sperl%{version} > +%{_bindir}/sperl%{perl_vers} > > %changelog > +* Mon Mar 5 2007 Tom "spot" Callaway - 4:5.8.8-14.1 > +- move ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, Test::Harness into devel > +- also move perlcc, perlivp, h2xs, libnetcfg to devel > + > * Tue Feb 27 2007 Robin Norwood - 4:5.8.8-14 > - Add a description for most of the patches, to reflect Spot's work to > report said patches upstream. -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From tcallawa at redhat.com Fri Mar 9 17:10:47 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Fri, 09 Mar 2007 11:10:47 -0600 Subject: Splitting out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker In-Reply-To: References: <1173417356.25839.400.camel@mccallum.corsepiu.local> Message-ID: <1173460247.4676.21.camel@localhost.localdomain> On Fri, 2007-03-09 at 11:28 -0500, Robin Norwood wrote: > Looks pretty good to me at first glace - I'm not totally convinced we > want to do this right now though...I'd like to get some more discussion > on the list first. > > We'll probably want to re-enable 'make test' at some point, too. ;-) > > Since this isn't quite done yet, how about: > > o I build a perl with all the changes except this one, including a > 'Requires: perl-devel' for the main perl package. > o We let people chime in on your changes over the weekend. > o If people like these changes, we'll get them into rawhide next week. It seems reasonable to me. There are some minor cosmetic changes I'd like to make (perl_version as opposed to perl_vers, use perl_version everywhere, macroize the other versions so they're easily fixable with new perl releases). I was initially concerned about circular deps (perl-devel will require all of these new subpackages), but perl won't need them as BuildRequires, so it should be ok. ~spot From rnorwood at redhat.com Fri Mar 9 20:54:59 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 09 Mar 2007 15:54:59 -0500 Subject: Splitting out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker In-Reply-To: <1173460247.4676.21.camel@localhost.localdomain> (Tom Callaway's message of "Fri, 09 Mar 2007 11:10:47 -0600") References: <1173417356.25839.400.camel@mccallum.corsepiu.local> <1173460247.4676.21.camel@localhost.localdomain> Message-ID: "Tom 'spot' Callaway" writes: > On Fri, 2007-03-09 at 11:28 -0500, Robin Norwood wrote: > >> Looks pretty good to me at first glace - I'm not totally convinced we >> want to do this right now though...I'd like to get some more discussion >> on the list first. >> >> We'll probably want to re-enable 'make test' at some point, too. ;-) >> >> Since this isn't quite done yet, how about: >> >> o I build a perl with all the changes except this one, including a >> 'Requires: perl-devel' for the main perl package. >> o We let people chime in on your changes over the weekend. >> o If people like these changes, we'll get them into rawhide next week. > > It seems reasonable to me. There are some minor cosmetic changes I'd > like to make (perl_version as opposed to perl_vers, use perl_version > everywhere, macroize the other versions so they're easily fixable with > new perl releases). > > I was initially concerned about circular deps (perl-devel will require > all of these new subpackages), but perl won't need them as > BuildRequires, so it should be ok. Ok - I've got a -15 run through the build system. It seems to work for me. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From tcallawa at redhat.com Sat Mar 10 16:57:11 2007 From: tcallawa at redhat.com (Tom 'spot' Callaway) Date: Sat, 10 Mar 2007 10:57:11 -0600 Subject: Splitting out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker In-Reply-To: References: <1173417356.25839.400.camel@mccallum.corsepiu.local> <1173460247.4676.21.camel@localhost.localdomain> Message-ID: <1173545831.30944.21.camel@localhost.localdomain> On Fri, 2007-03-09 at 15:54 -0500, Robin Norwood wrote: > "Tom 'spot' Callaway" writes: > > > On Fri, 2007-03-09 at 11:28 -0500, Robin Norwood wrote: > > > >> Looks pretty good to me at first glace - I'm not totally convinced we > >> want to do this right now though...I'd like to get some more discussion > >> on the list first. > >> > >> We'll probably want to re-enable 'make test' at some point, too. ;-) > >> > >> Since this isn't quite done yet, how about: > >> > >> o I build a perl with all the changes except this one, including a > >> 'Requires: perl-devel' for the main perl package. > >> o We let people chime in on your changes over the weekend. > >> o If people like these changes, we'll get them into rawhide next week. > > > > It seems reasonable to me. There are some minor cosmetic changes I'd > > like to make (perl_version as opposed to perl_vers, use perl_version > > everywhere, macroize the other versions so they're easily fixable with > > new perl releases). > > > > I was initially concerned about circular deps (perl-devel will require > > all of these new subpackages), but perl won't need them as > > BuildRequires, so it should be ok. > > Ok - I've got a -15 run through the build system. It seems to work for > me. One other item: We probably should subpackage ExtUtils-Embed too. ~spot From bugzilla at redhat.com Sun Mar 11 01:26:40 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 10 Mar 2007 20:26:40 -0500 Subject: [Bug 231744] New: error: Couldn't exec perl-devel-prov: No such file or directory Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 Summary: error: Couldn't exec perl-devel-prov: No such file or directory Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: redhat-bugzilla at linuxnetz.de QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: When rebuilding perl-5.8.8-15, I'm ending up with: --- snipp --- [...] Obsoletes: perl-Filter-Simple perl-Time-HiRes Processing files: perl-devel-5.8.8-15 error: Couldn't exec /usr/src/rpm/BUILD/perl-devel-5.8.8/perl-devel-prov: No such file or directory getOutputFrom(): Broken pipe --- snapp --- But when rebuilding perl-5.8.8-13, stuff works as expected. When comparing -13 and -15, I can't see the reason for the problem. Any ideas? Version-Release number of selected component (if applicable): perl-5.8.8-15 How reproducible: Everytime, see above. Actual results: No working rebuild. Expected results: Working rebuild. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Mar 11 15:41:36 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 11 Mar 2007 11:41:36 -0400 Subject: [Bug 230933] perl-Set-IntSpan-1.10 is available In-Reply-To: Message-ID: <200703111541.l2BFfaGP022990@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: perl-Set-IntSpan-1.10 is available https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=230933 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE ------- Additional Comments From ville.skytta at iki.fi 2007-03-11 11:41 EST ------- Built for FC6+, will be in the next push. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Mon Mar 12 07:01:47 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 12 Mar 2007 08:01:47 +0100 Subject: Splitting out CPAN, Test::Simple, Test::Harness, ExtUtils::MakeMaker In-Reply-To: <1173545831.30944.21.camel@localhost.localdomain> References: <1173417356.25839.400.camel@mccallum.corsepiu.local> <1173460247.4676.21.camel@localhost.localdomain> <1173545831.30944.21.camel@localhost.localdomain> Message-ID: <1173682908.3590.65.camel@mccallum.corsepiu.local> On Sat, 2007-03-10 at 10:57 -0600, Tom 'spot' Callaway wrote: > On Fri, 2007-03-09 at 15:54 -0500, Robin Norwood wrote: > > "Tom 'spot' Callaway" writes: > > > > > On Fri, 2007-03-09 at 11:28 -0500, Robin Norwood wrote: > > > > > >> Looks pretty good to me at first glace - I'm not totally convinced we > > >> want to do this right now though...I'd like to get some more discussion > > >> on the list first. > > >> > > >> We'll probably want to re-enable 'make test' at some point, too. ;-) > > >> > > >> Since this isn't quite done yet, how about: > > >> > > >> o I build a perl with all the changes except this one, including a > > >> 'Requires: perl-devel' for the main perl package. This would render the core purpose of this split ad absurdum. > > >> o We let people chime in on your changes over the weekend. > > >> o If people like these changes, we'll get them into rawhide next week. > > > > > > It seems reasonable to me. There are some minor cosmetic changes I'd > > > like to make (perl_version as opposed to perl_vers, use perl_version > > > everywhere, macroize the other versions so they're easily fixable with > > > new perl releases). A matter of personal preference, but no problem with me. > > > I was initially concerned about circular deps (perl-devel will require > > > all of these new subpackages), Hmm? Where do you see circular deps? Could you point them out? At least I don't see any. > > > but perl won't need them as > > > BuildRequires, so it should be ok. > > Ok - I've got a -15 run through the build system. It seems to work for > > me. > > One other item: > > We probably should subpackage ExtUtils-Embed too. I had considered doing this, but had abandoned this thought, because there doesn't seem to exist a current standalone ExtUtils::Embed perl dist (AFAIS, current EU::Embed's are only available through the main perl-tarball. The EU::Embed dist CPAN lists seems to refer to an abandoned version). Ralf From bugzilla at redhat.com Mon Mar 12 15:32:53 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 11:32:53 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121532.l2CFWrdF021637@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From rnorwood at redhat.com 2007-03-12 11:32 EST ------- strange - obviously seems related to the filtering of provides we do in the %prep section, starting around line 283: # Oh, the irony. Perl generates some non-versioned provides we don't need. # Each of these has a versioned provide, which we keep. cat << \EOF > %{name}-prov #!/bin/sh %{__perl_provides} $* |\ sed -e '/^perl(Carp)$/d' |\ sed -e '/^perl(DynaLoader)$/d' |\ sed -e '/^perl(Locale::Maketext)$/d' |\ sed -e '/^perl(Math::BigInt)$/d' |\ sed -e '/^perl(Net::Config)$/d' |\ sed -e '/^perl(Tie::Hash)$/d' |\ sed -e '/^perl(bigint)$/d' |\ sed -e '/^perl(bigrat)$/d' |\ sed -e '/^perl(bytes)$/d' |\ sed -e '/^perl(utf8)$/d' EOF %define __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov chmod +x %{__perl_provides} --------------- This is the standard method of filtering provides: http://fedoraproject.org/wiki/Packaging/Perl And I can't see why %{name} would be perl-devel instead of 'perl' - I thought %{name} was always the name of the source rpm. I also can't reproduce this here - can you send me your commandline and maybe ~/.rpmmacros ? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 15:44:54 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 11:44:54 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121544.l2CFisHd023493@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From rnorwood at redhat.com 2007-03-12 11:44 EST ------- Also, could you let me know what version of RPM you're using to build? Specifically, if you're using jbj's builds, this could be an implementation difference. Thanks. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 16:07:00 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 12:07:00 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121607.l2CG705D025219@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From tcallawa at redhat.com 2007-03-12 12:06 EST ------- %{name} should never be getting reassigned to perl-devel... very very strange. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 16:53:11 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 12:53:11 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121653.l2CGrBLi029037@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From rnorwood at redhat.com 2007-03-12 12:53 EST ------- background: Did some talking with nastrat and f13 on #fedora-devel - they agree that %{name} shouldn't be 'fedora-devel'. I'll try to reproduce this once I get more information from Robert. I'm thinking this is not a perl specfile bug, though. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 17:36:34 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 13:36:34 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121736.l2CHaY3n001398@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From redhat-bugzilla at linuxnetz.de 2007-03-12 13:36 EST ------- I read your talk at #fedora-devel. Well, when rebuilding of -13 works with the same RPM version used for -15 (where it fails), does it matter which RPM it is? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 17:38:49 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 13:38:49 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121738.l2CHcnRD001537@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From tcallawa at redhat.com 2007-03-12 13:38 EST ------- Yes, it does. No one can reproduce this with the RPM in Fedora. If you're using some other version of RPM, it is likely a bug in that other version of RPM, and not this perl spec file. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 17:58:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 13:58:52 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121758.l2CHwqFJ003249@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 ------- Additional Comments From rnorwood at redhat.com 2007-03-12 13:58 EST ------- Also, the spec file changed dramatically between -13 and -15. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 18:06:12 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 14:06:12 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703121806.l2CI6C6v003857@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 cweyl at alumni.drew.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fedora-perl-devel- | |list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 18:23:14 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 14:23:14 -0400 Subject: [Bug 231744] error: Couldn't exec perl-devel-prov: No such file or directory In-Reply-To: Message-ID: <200703121823.l2CINE4S005190@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: error: Couldn't exec perl-devel-prov: No such file or directory https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231744 redhat-bugzilla at linuxnetz.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC|fedora-perl-devel- |n3npq at mac.com |list at redhat.com | ------- Additional Comments From redhat-bugzilla at linuxnetz.de 2007-03-12 14:23 EST ------- Sorry, but your comment made me laughing. Did you ever do a diff between -13 and -15? You're adding some comments, changing description and moving a couple of files from perl core to -devel (which already exists in -13). Whatever means dramatically ;-) http://cvs.fedora.redhat.com/viewcvs/devel/perl/ perl.spec?r1=text&tr1=1.107&r2=text&tr2=1.109&diff_format=h Of course it could be a bug within upstream RPM, that's why I'm adding the long- time father. Jeff, I should be able to provide you a reproducer (if needed) when the rebuild of perl package I started now, fails once more. Walking home for now first... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 18:45:44 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 14:45:44 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703121845.l2CIjimK007205@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ville.skytta at iki.fi ------- Additional Comments From ville.skytta at iki.fi 2007-03-12 14:45 EST ------- I think a few cases like this have been hacked/worked around in the past using versioned Obsoletes, eg. in this case possibly adding "Obsoletes: perl < 5.8.8-14" in perl-devel would trick yum into doing the right thing. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 18:47:30 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 14:47:30 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703121847.l2CIlUQF007368@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 ------- Additional Comments From ville.skytta at iki.fi 2007-03-12 14:47 EST ------- Oops, perl has an Epoch set, so it should have been Obsoletes: perl < 4:5.8.8-14 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 18:58:17 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 14:58:17 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703121858.l2CIwHuK008121@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 ------- Additional Comments From tcallawa at redhat.com 2007-03-12 14:58 EST ------- I think we're also going to dodge this issue by making subpackage for the devel modules (e.g. perl-ExtUtils-MakeMaker). Ideally, I would hope that yum would only perform a shortest-name test after checking version and release of the conflicting packages (e.g. if I handed these to RPM, what would it do), but I know this is rather complicated. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 12 20:37:23 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 12 Mar 2007 16:37:23 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703122037.l2CKbNin015845@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 ------- Additional Comments From skvidal at linux.duke.edu 2007-03-12 16:37 EST ------- Created an attachment (id=149861) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=149861&action=view) patch to 3.0.4 which _should_ fix this bug please apply this to 3.0.4 and see if it solves this bug. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From steve at silug.org Tue Mar 13 22:50:11 2007 From: steve at silug.org (Steven Pritchard) Date: Tue, 13 Mar 2007 17:50:11 -0500 Subject: Pre-review: parrot and pugs In-Reply-To: <20070308224735.GA21225@osiris.silug.org> References: <20060627203020.GA31510@osiris.silug.org> <20070306012417.GA21218@osiris.silug.org> <20070308224735.GA21225@osiris.silug.org> Message-ID: <20070313225011.GA13824@osiris.silug.org> I've updated the parrot package now also: http://ftp.kspei.com/pub/steve/rpms/parrot-0.4.9-1.src.rpm http://ftp.kspei.com/pub/steve/rpms/parrot/parrot.spec Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From bugzilla at redhat.com Wed Mar 14 04:36:45 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Mar 2007 00:36:45 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703140436.l2E4ajbk002561@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 skvidal at linux.duke.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From skvidal at linux.duke.edu 2007-03-14 00:36 EST ------- confirmed fixed in patch. closing as nextrelease - 3.0.5 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 14 11:32:12 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Mar 2007 07:32:12 -0400 Subject: [Bug 232208] New: Missing dist tag Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232208 Summary: Missing dist tag Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-XML-Parser AssignedTo: rnorwood at redhat.com ReportedBy: oliver at linux-kernel.at CC: fedora-perl-devel-list at redhat.com Description of problem: Missing dist tag in release tag. Additional info: cvs diff: Diffing . Index: perl-XML-Parser.spec =================================================================== RCS file: /cvs/dist/devel/perl-XML-Parser/perl-XML-Parser.spec,v retrieving revision 1.19 diff -r1.19 perl-XML-Parser.spec 3c3 < Release: 6.1.2.2.1 --- > Release: 6.1.2.2.1%{?dist} -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 14 19:29:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Mar 2007 15:29:26 -0400 Subject: [Bug 167933] RFE: net-snmp: don't remove the tkmib perl script In-Reply-To: Message-ID: <200703141929.l2EJTQwV030070@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: RFE: net-snmp: don't remove the tkmib perl script https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167933 sghosh at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sghosh at redhat.com ------- Additional Comments From sghosh at redhat.com 2007-03-14 15:29 EST ------- With FC7 core and extras being merged - is this still an issue? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 14 20:14:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Mar 2007 16:14:52 -0400 Subject: [Bug 167933] RFE: net-snmp: don't remove the tkmib perl script In-Reply-To: Message-ID: <200703142014.l2EKEq1E002743@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: RFE: net-snmp: don't remove the tkmib perl script https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167933 ------- Additional Comments From jpo at di.uminho.pt 2007-03-14 16:14 EST ------- Yes. There are several files being removed in the specfile (one of them being tkmib). Net-snmp specfile ----------------- ... rm -f ${RPM_BUILD_ROOT}%{_bindir}/snmpinform rm -f ${RPM_BUILD_ROOT}%{_bindir}/tkmib rm -f ${RPM_BUILD_ROOT}%{_bindir}/snmpcheck rm -f ${RPM_BUILD_ROOT}%{_mandir}/man1/snmpconf.1* ln -s snmptrap ${RPM_BUILD_ROOT}/usr/bin/snmpinform ... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 14 20:21:16 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Mar 2007 16:21:16 -0400 Subject: [Bug 167933] RFE: net-snmp: don't remove the tkmib perl script In-Reply-To: Message-ID: <200703142021.l2EKLGXr003649@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: RFE: net-snmp: don't remove the tkmib perl script https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167933 ------- Additional Comments From jpo at di.uminho.pt 2007-03-14 16:21 EST ------- The tetex packager solved a problem similar to this one several years ago (the texdoctk perl script). See the following files in the tetex SRPM package: * tetex-3.0-tkdep.patch * tetex-filter-requires.sh jpo -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 15 03:08:04 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 14 Mar 2007 23:08:04 -0400 Subject: [Bug 232380] New: Pod::Readme: BR'ing perl(Test::Pod::Coverage) creates a circular BR loop Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232380 Summary: Pod::Readme: BR'ing perl(Test::Pod::Coverage) creates a circular BR loop Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-Pod-Readme AssignedTo: steve at silug.org ReportedBy: cweyl at alumni.drew.edu QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com Another fun circular BR loop :) Though this is seen when trying to rebuild perl-Module-Build: perl-Module-Build BR's perl(Pod::Readme) perl-Pod-Readme BR's perl(Test::Pod::Coverage) perl-Test-Pod-Coverage BR's perl(Pod::Coverage) perl-Pod-Coverage BR's perl(Module::Build) Since Test::Pod::Coverage is a developer test, and not needed for the build of perl-Pod-Readme, can we drop it as a BR to this package? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 15 18:24:07 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 15 Mar 2007 14:24:07 -0400 Subject: [Bug 232481] New: EPEL branches: a couple of perl packages from fedora.us Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232481 Summary: EPEL branches: a couple of perl packages from fedora.us Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-pmtools AssignedTo: jpo at di.uminho.pt ReportedBy: jpo at di.uminho.pt QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com Branches: EPEL4 and EPEL5 Perl packages to branch: * perl-pmtools * perl-ExtUtils-CBuilder * perl-ExtUtils-ParseXS Note: * Please create the EPEL branchs from the devel or FC-6 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 15 18:25:56 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 15 Mar 2007 14:25:56 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200703151825.l2FIPuwr001917@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: EPEL branches: a couple of perl packages from fedora.us https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232481 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |fedora-cvs? ------- Additional Comments From jpo at di.uminho.pt 2007-03-15 14:25 EST ------- Please read the previous comment. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 16 00:30:21 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 15 Mar 2007 20:30:21 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200703160030.l2G0ULgJ027002@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: EPEL branches: a couple of perl packages from fedora.us https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232481 jwboyer at jdub.homelinux.org changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs- ------- Additional Comments From jwboyer at jdub.homelinux.org 2007-03-15 20:30 EST ------- Please use the format documented here: http://fedoraproject.org/wiki/CVSAdminProcedure and set the fedora-cvs flag when completed. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 16 14:28:48 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 16 Mar 2007 10:28:48 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200703161428.l2GESmQe009259@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: EPEL branches: a couple of perl packages from fedora.us https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232481 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs- |fedora-cvs? ------- Additional Comments From jpo at di.uminho.pt 2007-03-16 10:28 EST ------- ======================= Package Name: perl-pmtools Short Description: A suite of small programs to help manage Perl modules Owners: jpo at di.uminho.pt Branches: EL-4 EL-5 InitialCC: fedora-perl-devel-list at redhat.com ======================= Package Name: perl-ExtUtils-CBuilder Short Description: Compile and link C code for Perl modules Owners: jpo at di.uminho.pt Branches: EL-4 EL-5 InitialCC: fedora-perl-devel-list at redhat.com ======================= Package Name: perl-ExtUtils-ParseXS Short Description: Module and a script for converting Perl XS code into C code Owners: jpo at di.uminho.pt Branches: EL-4 EL-5 InitialCC: fedora-perl-devel-list at redhat.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 16 18:34:56 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 16 Mar 2007 14:34:56 -0400 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200703161834.l2GIYueq030071@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-RPM2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 ------- Additional Comments From cweyl at alumni.drew.edu 2007-03-16 14:34 EST ------- Was this branched to extras cvs? I can't seem to find it in there. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 16 21:55:36 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 16 Mar 2007 17:55:36 -0400 Subject: [Bug 232736] New: perl-Pod-Readme: explicit requires on buildtime-only deps Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232736 Summary: perl-Pod-Readme: explicit requires on buildtime-only deps Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: medium Component: perl-Pod-Readme AssignedTo: steve at silug.org ReportedBy: cweyl at alumni.drew.edu QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com perl-Pod-Readme has explict "Requires:" listed for modules only needed at build time... These should be dropped. Requires: perl(Test::Pod) >= 1.00 Requires: perl(Test::Pod::Coverage) Requires: perl(Test::Portability::Files) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From steve at silug.org Sat Mar 17 01:26:43 2007 From: steve at silug.org (Steven Pritchard) Date: Fri, 16 Mar 2007 20:26:43 -0500 Subject: Packaging/Perl vs. PackagingTips/Perl Message-ID: <20070317012643.GA21968@osiris.silug.org> I noticed that there's a Packaging/Perl and a PackagingTips/Perl on the wiki. They have different content. Presumably they should be merged, but which of the two pages should be removed? It doesn't look like anyone else is using PackagingTips, so I'm guessing it should be that one. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve at kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320 From cweyl at alumni.drew.edu Sat Mar 17 03:23:22 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 16 Mar 2007 20:23:22 -0700 Subject: Packaging/Perl vs. PackagingTips/Perl In-Reply-To: <20070317012643.GA21968@osiris.silug.org> References: <20070317012643.GA21968@osiris.silug.org> Message-ID: <7dd7ab490703162023h2b05be5rf378bedbfcfdabc8@mail.gmail.com> On 3/16/07, Steven Pritchard wrote: > I noticed that there's a Packaging/Perl and a PackagingTips/Perl on > the wiki. They have different content. Presumably they should be > merged, but which of the two pages should be removed? > > It doesn't look like anyone else is using PackagingTips, so I'm > guessing it should be that one. The only issue I see with nuking PackagingTips/Perl (which I'd forgotten about... heh) is that anything under the Packaging namespace is ACL restricted. -Chris -- Chris Weyl Ex astris, scientia From bugzilla at redhat.com Mon Mar 19 01:32:03 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 18 Mar 2007 21:32:03 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200703190132.l2J1W3jB011847@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: EPEL branches: a couple of perl packages from fedora.us https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232481 wtogami at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag|fedora-cvs? |fedora-cvs+ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 21 16:09:24 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 21 Mar 2007 12:09:24 -0400 Subject: [Bug 216536] Review Request: FuzzyOcr - Checks for specific keywords in image attachments, using gocr In-Reply-To: Message-ID: <200703211609.l2LG9OqL032523@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: FuzzyOcr - Checks for specific keywords in image attachments, using gocr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216536 Bug 216536 depends on bug 216534, which changed state. Bug 216534 Summary: Review Request: gocr - GNU Optical Character Recognition program https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216534 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE Status|ASSIGNED |CLOSED -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 21 16:42:17 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 21 Mar 2007 12:42:17 -0400 Subject: [Bug 216536] Review Request: FuzzyOcr - Checks for specific keywords in image attachments, using gocr In-Reply-To: Message-ID: <200703211642.l2LGgHYM002653@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: FuzzyOcr - Checks for specific keywords in image attachments, using gocr https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=216536 ------- Additional Comments From greg at runlevel7.ca 2007-03-21 12:42 EST ------- Orion, we've updated our version to 3.5.1 (plus some fixes) and the spec file works with EL4 and EL5 now - should be good for Fedora6/7 too. http://smeserver.cvs.sourceforge.net/smeserver/FuzzyOcr/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 22 15:33:45 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 22 Mar 2007 11:33:45 -0400 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200703221533.l2MFXjQs029374@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: perl-RPM2 Alias: perl-RPM2 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=184530 cweyl at alumni.drew.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Alias| |perl-RPM2 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 23 01:02:59 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 22 Mar 2007 21:02:59 -0400 Subject: [Bug 233541] New: perl-perlmenu fails with getcap on perl5 Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233541 Summary: perl-perlmenu fails with getcap on perl5 Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: kwan at digitalhermit.com QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: Ttrying to use the perlmenu module returns the following error: Curses function 'getcap' is not defined by your vendor at /usr/lib/perl5/vendor_perl/5.8.8/perlmenu.pm line 382. Version-Release number of selected component (if applicable): perl-perlmenu-4.0-4.fc6 How reproducible: Call perlmenu function from withing a program. Steps to Reproduce: 1. yum install perl-perlmenu 2. cd /usr/share/doc/perl-perlmenu-x.x.x/examples 3. perl demo 2> outfile Actual results: Error log shows that getcap() from Curses is not available. Expected results: demo application should draw a curses menu system. Additional info: The perl-perlmenu package as shipped does not work with perl5. The original docs suggest the following change to /usr/lib/perl5/vendor_perl/5.8.8/perlmenu.pm: 108,113c108,113 < #if ($] >= 5.001) { # Perl5 ONLY! < #package Perl5::Menu_PL::Compat; # Don't pollute perlmenu.pm namespace < #require Term::Cap; # Get Tgetent package < #$term = Tgetent Term::Cap { OSPEED => 9600 }; # Define entry < #sub perlmenu::getcap { $term->{"_" . shift()} }; # Define local subroutine < #} --- > if ($] >= 5.001) { # Perl5 ONLY! > package Perl5::Menu_PL::Compat; # Don't pollute perlmenu.pm namespace > require Term::Cap; # Get Tgetent package > $term = Tgetent Term::Cap { OSPEED => 9600 }; # Define entry > sub perlmenu::getcap { $term->{"_" . shift()} }; # Define local subroutine > } -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Fri Mar 23 15:31:08 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 23 Mar 2007 11:31:08 -0400 Subject: [Bug 233541] perl-perlmenu fails with getcap on perl5 In-Reply-To: Message-ID: <200703231531.l2NFV8kL029227@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: perl-perlmenu fails with getcap on perl5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233541 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|perl-perlmenu fails with |perl-perlmenu fails with |getcap on perl5 |getcap on perl5 AssignedTo|rnorwood at redhat.com |panemade at gmail.com -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sat Mar 24 19:52:08 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 24 Mar 2007 15:52:08 -0400 Subject: [Bug 233767] New: perl-Gtk2-Ex-PodViewer should use standard perl(...) requires Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233767 Summary: perl-Gtk2-Ex-PodViewer should use standard perl(...) requires Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: low Priority: low Component: perl-Gtk2-Ex-PodViewer AssignedTo: bjohnson at symetrix.com ReportedBy: bjohnson at symetrix.com QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com Description of problem: perl-Gtk2-Ex-PodViewer should use standard perl(...) requires Version-Release number of selected component (if applicable): perl-Gtk2-Ex-PodViewer-0.17-1.fc6 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Mar 25 01:13:04 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 24 Mar 2007 21:13:04 -0400 Subject: [Bug 233796] New: Freshening perl requires perl-devel Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233796 Summary: Freshening perl requires perl-devel Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: ackistler at yahoo.com QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: Freshening perl requires perl-devel Version-Release number of selected component (if applicable): perl-5.8.8-15.fc7.i386.rpm How reproducible: Always Steps to Reproduce: 1. Freshen perl (rpm -F perl*) Actual results: perl-devel is needed by perl-5.8.8-15.fc7.i386 Expected results: perl should not require perl-devel to install or freshen Additional info: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Mar 25 20:01:47 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 25 Mar 2007 16:01:47 -0400 Subject: [Bug 233920] New: perl-Set-IntSpan-1.11 is available Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233920 Summary: perl-Set-IntSpan-1.11 is available Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: medium Component: perl-Set-IntSpan AssignedTo: ville.skytta at iki.fi ReportedBy: fevapp at o2.pl QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com perl-Set-IntSpan-1.11 is already available. Repo version is 1.10. Please update the package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Mar 25 20:19:16 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 25 Mar 2007 16:19:16 -0400 Subject: [Bug 233921] New: perl-MIME-Types-1.19 is available Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233921 Summary: perl-MIME-Types-1.19 is available Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: medium Component: perl-MIME-Types AssignedTo: ville.skytta at iki.fi ReportedBy: fevapp at o2.pl QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com perl-MIME-Types-1.19 is already available. Repo version is 1.18. Please update the package. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Sun Mar 25 21:08:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 25 Mar 2007 17:08:26 -0400 Subject: [Bug 233921] perl-MIME-Types-1.19 is available In-Reply-To: Message-ID: <200703252108.l2PL8QdH028851@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: perl-MIME-Types-1.19 is available https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233921 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE Fixed In Version| |1.19-1 ------- Additional Comments From ville.skytta at iki.fi 2007-03-25 17:08 EST ------- Done. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From jpazdziora at redhat.com Mon Mar 26 09:19:36 2007 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 26 Mar 2007 11:19:36 +0200 Subject: Packaging/Perl vs. PackagingTips/Perl In-Reply-To: <7dd7ab490703162023h2b05be5rf378bedbfcfdabc8@mail.gmail.com> References: <20070317012643.GA21968@osiris.silug.org> <7dd7ab490703162023h2b05be5rf378bedbfcfdabc8@mail.gmail.com> Message-ID: <20070326091936.GA4391@redhat.com> On Fri, Mar 16, 2007 at 08:23:22PM -0700, Chris Weyl wrote: > > The only issue I see with nuking PackagingTips/Perl (which I'd > forgotten about... heh) is that anything under the Packaging namespace > is ACL restricted. Can't we use PackagingTips/Perl as a staging area for changes made by public that would be incorporated into Packaging/Perl, then? -- Jan Pazdziora | adelton at #rhn*, #brno | RHN Sustaining Engineering, Red Hat From paul at city-fan.org Mon Mar 26 10:08:44 2007 From: paul at city-fan.org (Paul Howarth) Date: Mon, 26 Mar 2007 11:08:44 +0100 Subject: Packaging/Perl vs. PackagingTips/Perl In-Reply-To: <20070326091936.GA4391@redhat.com> References: <20070317012643.GA21968@osiris.silug.org> <7dd7ab490703162023h2b05be5rf378bedbfcfdabc8@mail.gmail.com> <20070326091936.GA4391@redhat.com> Message-ID: <46079BAC.4010303@city-fan.org> Jan Pazdziora wrote: > On Fri, Mar 16, 2007 at 08:23:22PM -0700, Chris Weyl wrote: >> The only issue I see with nuking PackagingTips/Perl (which I'd >> forgotten about... heh) is that anything under the Packaging namespace >> is ACL restricted. > > Can't we use PackagingTips/Perl as a staging area for changes made by > public that would be incorporated into Packaging/Perl, then? The conventional place for that would be called PackagingDrafts/Perl. Paul. From bugzilla at redhat.com Mon Mar 26 11:37:12 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 26 Mar 2007 07:37:12 -0400 Subject: [Bug 233541] perl-perlmenu fails with getcap on perl5 In-Reply-To: Message-ID: <200703261137.l2QBbCi5031348@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: perl-perlmenu fails with getcap on perl5 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233541 panemade at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From panemade at gmail.com 2007-03-26 07:37 EST ------- Updated in Rawhide with new version 4.0-4.1 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 26 14:36:06 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 26 Mar 2007 10:36:06 -0400 Subject: [Bug 233796] Freshening perl requires perl-devel In-Reply-To: Message-ID: <200703261436.l2QEa6HP012587@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Freshening perl requires perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233796 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From rnorwood at redhat.com 2007-03-26 10:35 EST ------- Thanks for the bug report, but this is a known issue. Right now perl 'requires' perl-devel: # XXX - remove this once RH bug #231549 is fixed Requires: perl-devel Since that bug is fixed, I'll remove the requirement for the next build of perl/perl-devel. *** This bug has been marked as a duplicate of 231549 *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 26 14:36:09 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 26 Mar 2007 10:36:09 -0400 Subject: [Bug 231549] yum fails to resolve dependancies when dep moves from perl to perl-devel In-Reply-To: Message-ID: <200703261436.l2QEa99x012632@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: yum fails to resolve dependancies when dep moves from perl to perl-devel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=231549 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ackistler at yahoo.com ------- Additional Comments From rnorwood at redhat.com 2007-03-26 10:36 EST ------- *** Bug 233796 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Mon Mar 26 17:27:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 26 Mar 2007 13:27:26 -0400 Subject: [Bug 233920] perl-Set-IntSpan-1.11 is available In-Reply-To: Message-ID: <200703261727.l2QHRQKe030175@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: perl-Set-IntSpan-1.11 is available https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233920 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |CURRENTRELEASE Fixed In Version| |1.11 ------- Additional Comments From ville.skytta at iki.fi 2007-03-26 13:27 EST ------- Done. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Wed Mar 28 21:30:09 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 28 Mar 2007 17:30:09 -0400 Subject: [Bug 234404] New: Cannot manage big listboxes with perl-Tk. Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234404 Summary: Cannot manage big listboxes with perl-Tk. Product: Fedora Core Version: devel Platform: i386 OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: pierre.lacaze at neuf.fr QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: Try to execute a little perl program (in attachment), creating a listbox of 200 entries, then try to select at the same time these entries. It fails. Version-Release number of selected component (if applicable): Fedora 7 test 2 How reproducible: perl bugperl.pl Actual results: A new listbox windows is displayed, but it disappears immediately, and the following error is displayed: selection conversion left too many bytes unconverted Abandon Expected results: Under windows (ActiveState Perl, + TK804 library), there is no error, and the listbox window is displayed properly. Additional info: see attachment. If you replace the 200 in the loop by 30, it works well. If you comment the $lbox->selectionSet(0,'end'); line, it works well too. ------- Additional Comments From pierre.lacaze at neuf.fr 2007-03-28 17:30 EST ------- Created an attachment (id=151170) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151170&action=view) Perl program which crashes. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 29 08:59:11 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 29 Mar 2007 04:59:11 -0400 Subject: [Bug 234439] New: Using perl's XML::LibXML Xpath function makes perl to crash Message-ID: Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234439 Summary: Using perl's XML::LibXML Xpath function makes perl to crash Product: Fedora Core Version: fc6 Platform: i386 OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-XML-LibXML AssignedTo: rnorwood at redhat.com ReportedBy: zby at post.cz CC: fedora-perl-devel-list at redhat.com Description of problem: I study xpath functions using perl's XML::LibXML and the result of one of my tests makes perl to end abnormaly dumping a backtrace and the memory map. I would expect either 0, undef, the xpath's "Invalid expression" or compile (sytax) error to result no matter how the xpath function is build or stated in the code. Version-Release number of selected component (if applicable): 2.6.20-1.2933.fc6 #1 SMP Mon Mar 19 10:42:48 EDT 2007 i686 i686 i386 GNU/Linux perl-5.8.8-10 perl-XML-LibXML-1.58-2.2.2.1 How reproducible: a single occurence - a technology study Steps to Reproduce: 1. 2. 3. Actual results: SIGABRT Expected results: 0, undef, the "Invalid expression" Xpath error or compile (sytax) error Additional info: Datiled steps I did are in the attachement ------- Additional Comments From zby at post.cz 2007-03-29 04:58 EST ------- Created an attachment (id=151183) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=151183&action=view) error dump plus history -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 29 15:22:04 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 29 Mar 2007 11:22:04 -0400 Subject: [Bug 234404] Cannot manage big listboxes with perl-Tk. In-Reply-To: Message-ID: <200703291522.l2TFM4bT029594@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Cannot manage big listboxes with perl-Tk. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234404 steve at silug.org changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Cannot manage big listboxes |Cannot manage big listboxes |with perl-Tk. |with perl-Tk. CC| |steve at silug.org, | |andreas.bierfert at lowlatency. | |de ------- Additional Comments From steve at silug.org 2007-03-29 11:21 EST ------- Is this using perl-Tk from Extras or a locally compiled module? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From bugzilla at redhat.com Thu Mar 29 19:29:40 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 29 Mar 2007 15:29:40 -0400 Subject: [Bug 234404] Cannot manage big listboxes with perl-Tk. In-Reply-To: Message-ID: <200703291929.l2TJTev3018852@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Cannot manage big listboxes with perl-Tk. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234404 ------- Additional Comments From pierre.lacaze at neuf.fr 2007-03-29 15:29 EST ------- I did not compile perl-Tk myself. Here is a yum info output. Name : perl-Tk Arch : i386 Version: 804.027 Release: 10.fc6 Size : 6.7 M Repo : installed Summary: Perl Graphical User Interface ToolKit Name : perl Arch : i386 Epoch : 4 Version: 5.8.8 Release: 15.fc7 Size : 28 M Repo : installed Summary: The Perl programming language -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rnorwood at redhat.com Wed Mar 28 19:33:44 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 28 Mar 2007 15:33:44 -0400 Subject: New perl spec file Message-ID: Hi, Sorry for the delay, but here's a new perl spec file including Ralf and Tom's changes, removing the Requires: perl-devel, and a couple of minor cleanups from me. It seems to build, except on s390... I'll look into that. Comments? -------------- next part -------------- %define multilib_64_archs x86_64 s390x ppc64 sparc64 %define perl_archname %{_arch}-%{_os}-thread-multi %define perlmodcompat 5.8.7 5.8.6 5.8.5 %define new_perl_lib $RPM_BUILD_ROOT%{_libdir}/perl5/%{version}:$RPM_BUILD_ROOT/usr/lib/perl5/%{version} %define comp_perl_lib $RPM_BUILD_ROOT/usr/lib/perl5/%{version}:$RPM_BUILD_ROOT/usr/lib/perl5/%{version} %define new_arch_lib $RPM_BUILD_ROOT%{_libdir}/perl5/%{version}/%{perl_archname} %define comp_arch_lib $RPM_BUILD_ROOT/usr/lib/perl5/%{version}/%{perl_archname} %define new_perl_flags LD_PRELOAD=/%{new_arch_lib}/CORE/libperl.so LD_LIBRARY_PATH=%{new_arch_lib}/CORE PERL5LIB=%{new_perl_lib}:%{comp_perl_lib} %define new_perl %{new_perl_flags} $RPM_BUILD_ROOT/%{_bindir}/perl %define perl_version 5.8.8 # Use this for SUPER PERL DEBUGGING MODE. %{?!perl_debugging: %define perl_debugging 0} %if %{perl_debugging} %define debug_package %{nil} # don't build debuginfo and disable stripping %endif Name: perl Version: 5.8.8 Release: 16%{?dist} Epoch: 4 Summary: The Perl programming language Group: Development/Languages License: Artistic or GPL Url: http://www.perl.org/ Source0: http://www.cpan.org/authors/id/N/NW/NWCLARK/%{name}-%{perl_version}.tar.bz2 Source11: filter-depends.sh Source12: perl-5.8.0-libnet.cfg # Specific to Fedora/RHEL Patch1: perl-5.8.0-root.patch # Upstream bug 41586 Patch2: perl-5.8.8-incpush.patch # Removes date check, Fedora/RHEL specific Patch3: perl-5.8.8-perlbug-tag.patch # XXX: The next two patches appear to alter the order of @INC, but # there isn't sufficient documentation as to why we do this. Patch4: perl-5.8.8-dashI.patch Patch5: perl-5.8.5-incorder.patch # make sure we get the proper ldflags on libperl.so # Upstream bug 41587 Patch6: perl-5.8.0-sharedlinker.patch # Fedora/RHEL use links instead of lynx Patch7: perl-5.8.8-links.patch # work around annoying rpath issue # This is only relevant for Fedora, as it is unlikely # that upstream will assume the existence of a libperl.so Patch8: perl-5.8.8-rpath-make.patch # Disable -DDEBUGGING and allow -g to do its job (#156113) # Upstream bug 41588 Patch9: perl-5.8.7-no-debugging.patch # Upstream bug 41589 Patch10: perl-5.8.1-fpic.patch # Fedora/RHEL only (64bit only) Patch11: perl-5.8.0-libdir64.patch # Upstream bug 41590 Patch12: perl-5.8.0-nptlhint.patch # Fedora/RHEL specific (use libresolv instead of libbind) Patch13: perl-5.8.6-libresolv.patch # fix for bug 163958 / upstream bug 37056 : # backport of perl-5.9's patch 25084 (bug still in 5.8.8!): Patch14: perl-5.8.7-25084.patch # multi-threaded perl builds use localtime_r which does not call tzset # bugzilla 172396 # Upstream bug 41591 Patch15: perl-5.8.7-172396.patch # Security fix Patch16: perl-5.8.8-CAN-2004-0976.patch # XXX: Fixme # Needs all the "Red Hat" references removed before upstreaming Patch17: perl-5.8.8-USE_MM_LD_RUN_PATH.patch # Upstream bug 38385 Patch18: perl-5.8.8-bz178343.patch # Debian's fix for Net::NNTP: # Upstream bug 41593 Patch19: perl-5.8.8-debian_fix_net_nntp.patch # Upstream patches 27133 and 27169 (27170): Patch20: perl-5.8.8-up27133_up27169.patch # Upstream patch 27284: Patch21: perl-5.8.8-up27284.patch # Fix for bug 183553 / upstream bug 38657: Patch22: perl-5.8.8-bz183553_ubz38657.patch # http://rt.cpan.org/Ticket/Display.html?id=18692 Patch23: perl-5.8.8-bz188441.patch # Upstream bug 39130 Patch24: perl-5.8.8-bz191416.patch Patch25: perl-5.8.8-U27116.patch Patch26: perl-5.8.8-U27391.patch Patch27: perl-5.8.8-U27426.patch Patch28: perl-5.8.8-U27509.patch Patch29: perl-5.8.8-U27512.patch Patch30: perl-5.8.8-U27604.patch Patch31: perl-5.8.8-U27605.patch Patch32: perl-5.8.8-U27914.patch Patch33: perl-5.8.8-U27329.patch # XXX: Fixme # Needs to be un-RedHatized before upstreaming Patch34: perl-5.8.8-R-switch.patch # stop IPC/SysV.c including for getpagesize(), which # is now declared by including . # Upstream bug 41594 Patch35: perl-5.8.8-no_asm_page_h.patch Patch36: perl-5.8.8-U34297_C28006.patch # Bugzilla 199372 # Upstream bug 41595 Patch37: perl-5.8.8-useCFLAGSwithCC.patch # Upstream bug 39903 Patch38: perl-5.8.8-bz199736.patch # XXX: Fixme - Finish patch. Patch39: perl-5.8.8-bz204679.patch BuildRoot: %{_tmppath}/%{name}-%{perl_version}-%{release}-root-%(%{__id_u} -n) BuildRequires: tcsh, dos2unix, man, groff BuildRequires: gdbm-devel, db4-devel # The long line of Perl provides. # These provides are needed by the perl pkg itself with auto-generated perl.req Provides: perl(VMS::Filespec) Provides: perl(VMS::Stdio) # Compat provides Provides: perl(:MODULE_COMPAT_5.8.5) Provides: perl(:MODULE_COMPAT_5.8.6) Provides: perl(:MODULE_COMPAT_5.8.7) Provides: perl(:MODULE_COMPAT_5.8.8) # Threading provides Provides: perl(:WITH_ITHREADS) Provides: perl(:WITH_THREADS) # Largefile provides Provides: perl(:WITH_LARGEFILES) # PerlIO provides Provides: perl(:WITH_PERLIO) # File provides Provides: perl(abbrev.pl) Provides: perl(assert.pl) Provides: perl(bigfloat.pl) Provides: perl(bigint.pl) Provides: perl(bigrat.pl) Provides: perl(bytes_heavy.pl) Provides: perl(cacheout.pl) Provides: perl(complete.pl) Provides: perl(ctime.pl) Provides: perl(dotsh.pl) Provides: perl(dumpvar.pl) Provides: perl(exceptions.pl) Provides: perl(fastcwd.pl) Provides: perl(find.pl) Provides: perl(finddepth.pl) Provides: perl(flush.pl) Provides: perl(ftp.pl) Provides: perl(getcwd.pl) Provides: perl(getopt.pl) Provides: perl(getopts.pl) Provides: perl(hostname.pl) Provides: perl(importenv.pl) Provides: perl(look.pl) Provides: perl(newgetopt.pl) Provides: perl(open2.pl) Provides: perl(open3.pl) Provides: perl(perl5db.pl) Provides: perl(pwd.pl) Provides: perl(shellwords.pl) Provides: perl(stat.pl) Provides: perl(syslog.pl) Provides: perl(tainted.pl) Provides: perl(termcap.pl) Provides: perl(timelocal.pl) Provides: perl(utf8_heavy.pl) Provides: perl(validate.pl) Provides: perl(Carp::Heavy) # Versioned Provides for our Obsoletes Provides: perl-Filter-Simple = 0.82 Provides: perl-Time-HiRes = 1.86 # Last seen in Fedora Core 4 Obsoletes: perl-Filter-Simple Obsoletes: perl-Time-HiRes %define __perl_requires %{SOURCE11} %description Perl is a high-level programming language with roots in C, sed, awk and shell scripting. Perl is good at handling processes and files, and is especially good at handling text. Perl's hallmarks are practicality and efficiency. While it is used to do a lot of different things, Perl's most common applications are system administration utilities and web programming. A large proportion of the CGI scripts on the web are written in Perl. You need the perl package installed on your system so that your system can handle Perl scripts. Install this package if you want to program in Perl or enable your system to handle Perl scripts. %package devel Summary: Header files for use in perl development Group: Development/Languages Requires: perl = %{epoch}:%{perl_version}-%{release} %description devel This package contains header files and development modules. Most perl packages will need to install perl-devel to build. %package suidperl Summary: Suidperl, for use with setuid perl scripts Group: Development/Languages Requires: perl = %{epoch}:%{perl_version}-%{release} %description suidperl Suidperl is a setuid binary copy of perl that allows for (hopefully) more secure running of setuid perl scripts. %package CPAN Summary: Query, download and build perl modules from CPAN sites Group: Development/Languages Epoch: 0 Version: 1.76_02 Requires: perl = %{epoch}:%{perl_version}-%{release} %description CPAN Query, download and build perl modules from CPAN sites. %package ExtUtils-Embed Summary: Utilities for embedding Perl in C/C++ applications Group: Development/Languages Epoch: 0 Version: 1.26 Requires: perl-devel Requires: perl = %{epoch}:%{perl_version}-%{release} %description ExtUtils-Embed Utilities for embedding Perl in C/C++ applications. %package ExtUtils-MakeMaker Summary: Create a module Makefile Group: Development/Languages Epoch: 0 Version: 6.30 Requires: perl-devel Requires: perl = %{epoch}:%{perl_version}-%{release} %description ExtUtils-MakeMaker Create a module Makefile. %package Test-Harness Summary: Run Perl standard test scripts with statistics Group: Development/Languages Epoch: 0 Version: 2.56 Requires: perl-devel Requires: perl = %{epoch}:%{perl_version}-%{release} %description Test-Harness Run Perl standard test scripts with statistics. %package Test-Simple Summary: Basic utilities for writing tests Group: Development/Languages Epoch: 0 Version: 0.62 Requires: perl-devel Requires: perl = %{epoch}:%{perl_version}-%{release} %description Test-Simple Basic utilities for writing tests. %prep %setup -q %patch1 -p1 %patch2 -p1 %patch3 -p1 %patch4 -p1 %patch5 -p1 %patch6 -p1 %patch7 -p1 %patch8 -p1 %if !%{perl_debugging} %patch9 -p1 %endif %patch10 -p1 %ifarch %{multilib_64_archs} %patch11 -p1 %endif %patch12 -p1 %patch13 -p1 %patch14 -p1 %patch15 -p1 %patch16 -p1 %patch17 -p1 %patch18 -p1 %patch19 -p1 %patch20 -p1 %patch21 -p1 %patch22 -p1 %patch23 -p1 %patch24 -p1 %patch25 -p1 %patch26 -p1 %patch27 -p1 %patch28 -p1 %patch29 -p1 %patch30 -p1 %patch31 -p1 %patch32 -p1 %patch33 -p1 %patch34 -p1 %patch35 -p1 %patch36 -p1 %patch37 -p1 %patch38 -p1 # # Candidates for doc recoding (need case by case review): # find . -name "*.pod" -o -name "README*" -o -name "*.pm" | xargs file -i | grep charset= | grep -v '\(us-ascii\|utf-8\)' recode() { iconv -f "$2" -t utf-8 < "$1" > "${1}_" mv -f "${1}_" "$1" } recode README.cn euc-cn recode README.jp euc-jp recode README.ko euc-kr recode README.tw big5 recode pod/perlebcdic.pod iso-8859-1 recode pod/perlhack.pod iso-8859-1 recode pod/perlhist.pod iso-8859-1 recode pod/perlothrtut.pod iso-8859-1 recode pod/perlthrtut.pod iso-8859-1 recode lib/Unicode/Collate.pm iso-8859-1 find . -name \*.orig -exec rm -fv {} \; # Oh, the irony. Perl generates some non-versioned provides we don't need. # Each of these has a versioned provide, which we keep. cat << \EOF > %{name}-prov #!/bin/sh %{__perl_provides} $* |\ sed -e '/^perl(Carp)$/d' |\ sed -e '/^perl(DynaLoader)$/d' |\ sed -e '/^perl(Locale::Maketext)$/d' |\ sed -e '/^perl(Math::BigInt)$/d' |\ sed -e '/^perl(Net::Config)$/d' |\ sed -e '/^perl(Tie::Hash)$/d' |\ sed -e '/^perl(bigint)$/d' |\ sed -e '/^perl(bigrat)$/d' |\ sed -e '/^perl(bytes)$/d' |\ sed -e '/^perl(utf8)$/d' EOF %define __perl_provides %{_builddir}/%{name}-%{perl_version}/%{name}-prov chmod +x %{__perl_provides} %build echo "RPM Build arch: %{_arch}" # yes; don't use %_libdir so that noarch packages from other OSs # arches work correctly :\ the Configure lines below hardcode lib for # similar reasons. sh Configure -des -Doptimize="$RPM_OPT_FLAGS" \ -Dversion=%{perl_version} \ -Dmyhostname=localhost \ -Dperladmin=root at localhost \ -Dcc='%{__cc}' \ -Dcf_by='Red Hat, Inc.' \ -Dinstallprefix=%{_prefix} \ -Dprefix=%{_prefix} \ %ifarch %{multilib_64_archs} -Dlibpth="/usr/local/lib64 /lib64 /usr/lib64" \ -Dprivlib="/usr/lib/perl5/%{perl_version}" \ -Dsitelib="/usr/lib/perl5/site_perl/%{perl_version}" \ -Dvendorlib="/usr/lib/perl5/vendor_perl/%{perl_version}" \ -Darchlib="%{_libdir}/perl5/%{perl_version}/%{perl_archname}" \ -Dsitearch="%{_libdir}/perl5/site_perl/%{perl_version}/%{perl_archname}" \ -Dvendorarch="%{_libdir}/perl5/vendor_perl/%{perl_version}/%{perl_archname}" \ %endif -Darchname=%{_arch}-%{_os} \ %ifarch sparc -Ud_longdbl \ %endif -Dvendorprefix=%{_prefix} \ -Dsiteprefix=%{_prefix} \ -Duseshrplib \ -Dusethreads \ -Duseithreads \ -Duselargefiles \ -Dd_dosuid \ -Dd_semctl_semun \ -Di_db \ -Ui_ndbm \ -Di_gdbm \ -Di_shadow \ -Di_syslog \ -Dman3ext=3pm \ -Duseperlio \ -Dinstallusrbinperl=n \ -Ubincompat5005 \ -Uversiononly \ -Dpager='/usr/bin/less -isr' \ -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto \ -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto \ -Ud_endservent_r_proto -Ud_setservent_r_proto \ -Dinc_version_list='%{perlmodcompat}' \ -Dscriptdir='%{_bindir}' make %{?_smp_mflags} %install rm -rf $RPM_BUILD_ROOT make install DESTDIR=$RPM_BUILD_ROOT %ifarch %{multilib_64_archs} mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_version} mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/site_perl/%{perl_version} mkdir -p -m 755 $RPM_BUILD_ROOT/usr/lib/perl5/vendor_perl/%{perl_version} %endif %ifarch %{multilib_64_archs} mkdir -p -m 755 ${RPM_BUILD_ROOT}/usr/lib64/perl5/vendor_perl/%{perl_version}/%{_arch}-%{_os} %endif # # Compatibility directories # pushd $RPM_BUILD_ROOT/%{_libdir}/perl5 for i in %{perlmodcompat}; do mkdir -pm 755 $i/%{perl_archname}/CORE mkdir -pm 755 $i/%{perl_archname}/auto pushd $i/%{perl_archname}/CORE ln -s ../../../%{perl_version}/%{perl_archname}/CORE/libperl.so libperl.so popd done popd install -p -m 755 utils/pl2pm ${RPM_BUILD_ROOT}%{_bindir}/pl2pm for i in asm/termios.h syscall.h syslimits.h syslog.h sys/ioctl.h sys/socket.h sys/time.h wait.h do %{new_perl} $RPM_BUILD_ROOT/%{_bindir}/h2ph -a \ -d $RPM_BUILD_ROOT%{_libdir}/perl5/%{perl_version}/%{perl_archname} $i || /bin/true done for dir in $(%{new_perl} -le 'print join("\n", @INC)' | grep '^/usr/lib') do mkdir -p $RPM_BUILD_ROOT/$dir done for dir in $(%{new_perl} -le 'print join("\n", @INC)' | grep '^%{_libdir}') do mkdir -p $RPM_BUILD_ROOT/$dir done for i in %{perl_version} %{perlmodcompat} ; do mkdir -pm 755 $RPM_BUILD_ROOT%{_libdir}/perl5/site_perl/$i/%{perl_archname}/auto mkdir -pm 755 $RPM_BUILD_ROOT%{_libdir}/perl5/vendor_perl/$i/%{perl_archname}/auto done # # libnet configuration file # mkdir -p -m 755 $RPM_BUILD_ROOT/%{_libdir}/perl5/%{perl_version}/Net install -p -m 644 %{SOURCE12} $RPM_BUILD_ROOT/%{_libdir}/perl5/%{perl_version}/Net/libnet.cfg # # Core modules removal # find $RPM_BUILD_ROOT -name '*NDBM*' | xargs rm -rfv find $RPM_BUILD_ROOT -type f -name '*.bs' -a -empty -exec rm -f {} ';' # Cleanup binary paths and make cgi files executable pushd $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_version}/CGI/eg/ for i in *.cgi make_links.pl RunMeFirst ; do sed -i 's|/usr/local/bin/perl|/usr/bin/perl|g' $i chmod +x $i done popd # miniperl? As an interpreter? How odd. sed -i 's|./miniperl|/usr/bin/perl|' $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_version}/ExtUtils/xsubpp chmod +x $RPM_BUILD_ROOT/usr/lib/perl5/%{perl_version}/ExtUtils/xsubpp # Don't need the .packlist rm -f $RPM_BUILD_ROOT%{_libdir}/perl5/%{perl_version}/%{perl_archname}/.packlist # Fix some manpages to be UTF-8 pushd $RPM_BUILD_ROOT%{_mandir}/man1/ for i in perl588delta.1 perldelta.1 ; do iconv -f MS-ANSI -t UTF-8 $i --output new-$i rm -rf $i mv new-$i $i done popd chmod -R u+w $RPM_BUILD_ROOT/* %if %{perl_debugging} exit 0 # disable brp-strip %endif %clean rm -rf $RPM_BUILD_ROOT %check make test %files %defattr(-,root,root,-) %doc Copying README %{_mandir}/man1/*.1* %{_mandir}/man3/*.3* %{_bindir}/* %{_libdir}/perl5/ %ifarch %{multilib_64_archs} /usr/lib/perl5/ %endif # devel %exclude %{_bindir}/enc2xs %exclude %{_mandir}/man1/enc2xs* %exclude %{_bindir}/h2xs %exclude %{_mandir}/man1/h2xs* %exclude %{_bindir}/libnetcfg %exclude %{_mandir}/man1/libnetcfg* %exclude %{_bindir}/perlcc %exclude %{_mandir}/man1/perlcc* %exclude %{_bindir}/perlivp %exclude %{_mandir}/man1/perlivp* %exclude %{_libdir}/perl5/%{perl_version}/%{perl_archname}/CORE/*.h # suidperl %exclude %{_bindir}/suidperl %exclude %{_bindir}/sperl%{perl_version} # CPAN %exclude %{_bindir}/cpan %exclude /usr/lib/perl5/%{perl_version}/CPAN/ %exclude /usr/lib/perl5/%{perl_version}/CPAN.pm %exclude %{_mandir}/man1/cpan.1* %exclude %{_mandir}/man3/CPAN* # ExtUtils-Embed %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Embed.pm %exclude %{_mandir}/man3/ExtUtils::Embed* # ExtUtils-MakeMaker %exclude %{_bindir}/instmodsh %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Command/ %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Install.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Installed.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Liblist/ %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Liblist.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/MakeMaker/ %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/MakeMaker.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/MANIFEST.SKIP %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/MM*.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/MY.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Manifest.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Mkbootstrap.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Mksymlists.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/NOTES %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/Packlist.pm %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/PATCHING %exclude /usr/lib/perl5/%{perl_version}/ExtUtils/testlib.pm %exclude %{_mandir}/man1/instmodsh.1* %exclude %{_mandir}/man3/ExtUtils::Command::MM* %exclude %{_mandir}/man3/ExtUtils::Install.3* %exclude %{_mandir}/man3/ExtUtils::Installed.3* %exclude %{_mandir}/man3/ExtUtils::Liblist.3* %exclude %{_mandir}/man3/ExtUtils::MM* %exclude %{_mandir}/man3/ExtUtils::MY.3* %exclude %{_mandir}/man3/ExtUtils::MakeMaker* %exclude %{_mandir}/man3/ExtUtils::Manifest.3* %exclude %{_mandir}/man3/ExtUtils::Mkbootstrap.3* %exclude %{_mandir}/man3/ExtUtils::Mksymlists.3* %exclude %{_mandir}/man3/ExtUtils::Packlist.3* %exclude %{_mandir}/man3/ExtUtils::testlib.3* # Test::Harness %exclude %{_bindir}/prove %exclude /usr/lib/perl5/%{perl_version}/Test/Harness* %exclude %{_mandir}/man1/prove.1* %exclude %{_mandir}/man3/Test::Harness* # Test::Simple %exclude /usr/lib/perl5/%{perl_version}/Test/More* %exclude /usr/lib/perl5/%{perl_version}/Test/Builder* %exclude /usr/lib/perl5/%{perl_version}/Test/Simple* %exclude /usr/lib/perl5/%{perl_version}/Test/Tutorial* %exclude %{_mandir}/man3/Test::More* %exclude %{_mandir}/man3/Test::Builder* %exclude %{_mandir}/man3/Test::Simple* %exclude %{_mandir}/man3/Test::Tutorial* %files devel %defattr(-,root,root,-) %{_bindir}/enc2xs %{_mandir}/man1/enc2xs* %{_bindir}/h2xs %{_mandir}/man1/h2xs* %{_bindir}/libnetcfg %{_mandir}/man1/libnetcfg* %{_bindir}/perlcc %{_mandir}/man1/perlcc* %{_bindir}/perlivp %{_mandir}/man1/perlivp* %{_libdir}/perl5/%{perl_version}/%{perl_archname}/CORE/*.h %files suidperl %defattr(-,root,root,-) %{_bindir}/suidperl %{_bindir}/sperl%{perl_version} %files CPAN %defattr(-,root,root,-) %{_bindir}/cpan /usr/lib/perl5/%{perl_version}/CPAN/ /usr/lib/perl5/%{perl_version}/CPAN.pm %{_mandir}/man1/cpan.1* %{_mandir}/man3/CPAN* %files ExtUtils-Embed %defattr(-,root,root,-) /usr/lib/perl5/%{perl_version}/ExtUtils/Embed.pm %{_mandir}/man3/ExtUtils::Embed* %files ExtUtils-MakeMaker %defattr(-,root,root,-) %{_bindir}/instmodsh /usr/lib/perl5/%{perl_version}/ExtUtils/Command/ /usr/lib/perl5/%{perl_version}/ExtUtils/Install.pm /usr/lib/perl5/%{perl_version}/ExtUtils/Installed.pm /usr/lib/perl5/%{perl_version}/ExtUtils/Liblist/ /usr/lib/perl5/%{perl_version}/ExtUtils/Liblist.pm /usr/lib/perl5/%{perl_version}/ExtUtils/MakeMaker/ /usr/lib/perl5/%{perl_version}/ExtUtils/MakeMaker.pm /usr/lib/perl5/%{perl_version}/ExtUtils/MANIFEST.SKIP /usr/lib/perl5/%{perl_version}/ExtUtils/MM*.pm /usr/lib/perl5/%{perl_version}/ExtUtils/MY.pm /usr/lib/perl5/%{perl_version}/ExtUtils/Manifest.pm /usr/lib/perl5/%{perl_version}/ExtUtils/Mkbootstrap.pm /usr/lib/perl5/%{perl_version}/ExtUtils/Mksymlists.pm /usr/lib/perl5/%{perl_version}/ExtUtils/NOTES /usr/lib/perl5/%{perl_version}/ExtUtils/Packlist.pm /usr/lib/perl5/%{perl_version}/ExtUtils/PATCHING /usr/lib/perl5/%{perl_version}/ExtUtils/testlib.pm %{_mandir}/man1/instmodsh.1* %{_mandir}/man3/ExtUtils::Command::MM* %{_mandir}/man3/ExtUtils::Install.3* %{_mandir}/man3/ExtUtils::Installed.3* %{_mandir}/man3/ExtUtils::Liblist.3* %{_mandir}/man3/ExtUtils::MM* %{_mandir}/man3/ExtUtils::MY.3* %{_mandir}/man3/ExtUtils::MakeMaker* %{_mandir}/man3/ExtUtils::Manifest.3* %{_mandir}/man3/ExtUtils::Mkbootstrap.3* %{_mandir}/man3/ExtUtils::Mksymlists.3* %{_mandir}/man3/ExtUtils::Packlist.3* %{_mandir}/man3/ExtUtils::testlib.3* %files Test-Harness %defattr(-,root,root,-) %{_bindir}/prove /usr/lib/perl5/%{perl_version}/Test/Harness* %{_mandir}/man1/prove.1* %{_mandir}/man3/Test::Harness* %files Test-Simple %defattr(-,root,root,-) /usr/lib/perl5/%{perl_version}/Test/More* /usr/lib/perl5/%{perl_version}/Test/Builder* /usr/lib/perl5/%{perl_version}/Test/Simple* /usr/lib/perl5/%{perl_version}/Test/Tutorial* %{_mandir}/man3/Test::More* %{_mandir}/man3/Test::Builder* %{_mandir}/man3/Test::Simple* %{_mandir}/man3/Test::Tutorial* %changelog * Wed Mar 28 2007 Robin Norwood - 4:5.8.8-16 - Includes patch from Ralf Corsepius to split out some more perl modules. - Further split out development related perl modules. - Remove Requires: perl-devel from perl * Fri Mar 9 2007 Robin Norwood - 4:5.8.8-15 - Incorporate fixes from spot and others on fedora-perl-devel - The main perl package will temporarily Require perl-devel - move ExtUtils::MakeMaker, ExtUtils::Embed, CPAN, Test::Harness into devel - also move perlcc, perlivp, h2xs, libnetcfg to devel * Tue Feb 27 2007 Robin Norwood - 4:5.8.8-14 - Add a description for most of the patches, to reflect Spot's work to report said patches upstream. * Sat Feb 3 2007 Tom "spot" Callaway - 4:5.8.8-13 - massive cleanups * Wed Jan 24 2007 Jindrich Novy - 4:5.8.8-12 - put dist tag directly to perlrel to fix dependency to suidperl * Tue Jan 23 2007 Jindrich Novy - 4:5.8.8-11 - rebuild against new db4 - use dist tag * Sat Sep 30 2006 Robin Norwood - 4:5.8.8-10 - bugzilla: 208731 - remove directory support for old perl versions * Fri Sep 15 2006 Robin Norwood - 4:5.8.8-9 - fix bug 204679: add Unicode 5.0.0 support * Fri Jul 21 2006 Jason Vas Dias - 4:5.8.8-8 - fix bug 199736: make perlcc handle floating point values * Wed Jul 19 2006 Jason Vas Dias - 4:5.8.8-8 - fix bug 199372: add .so cflags for sparc64 * Fri Jul 14 2006 Jason Vas Dias - 4:5.8.8-8 - Fix upstream perl bug #34297: 'utf8 overload stringify bug (utf8 caching maybe)' upstream patch #28006 applied * Wed Jul 12 2006 Jesse Keating - 4:5.8.8-6.1 - rebuild * Thu Jun 01 2006 Jason Vas Dias - 4:5.8.8-6 - Fix upstream perl bug #38454: 'rindex corrects for $[ on bytes rather than UTF-8' apply upstream patch #27116 - Fix upstream perl bug 24816: 'Magic vars seem unsure if they are purely numeric' ( perl -wle 'print $? = $? ^ "3"' -> 'Argument "^C" isn't numeric' ) apply upstream patch #27391 - Avoid writing over the input string in the case 'F' in moreswitches. apply upstream patch #27426 - Fix upstream perl bug 34925 - 'overload and rebless' - apply upstream patches #27509, #27512 - Fix upstream perl bug 3038 - '$qr = qr/^a$/m; $x =~ $qr; fails' apply upstream patch #27604 - apply upstream patch #27605 - 'Fix off-by-one in $0 set magic.' - Fix upstream perl bug 23141 - '($_) = () fails to set $_ to undef' apply upstream patch #27914 - Fix upstream perl bug #38619 - 'Bug in lc and uc (interaction between UTF-8, substr, and lc/uc)' apply upstream patch #27329 - Give users the '-R' option to disable the Red Hat module compatibility default search path extension (incpush.patch). * Thu May 11 2006 Jason Vas Dias - 4:5.8.8-6 - Fix bug 191416: make h2ph generate correct code for cpp statements like: '#if defined A || defined B' - Fix 172396.patch for non-threaded builds * Wed Apr 12 2006 Jason Vas Dias - 4:5.8.8-6 - Fix bug 188841: make CGI.pm's url(-relative) handle rewrites * Tue Mar 01 2006 Jason Vas Dias - 4:5.8.8-4 - Fix bug 183553 / upstream bug 38657: fix -d:Foo=bar processing - rebuild with new gcc-4.1.0-1, released today * Mon Feb 27 2006 Jason Vas Dias - Apply upstream patch #28284 * Mon Feb 13 2006 Jason Vas Dias - 4:5.8.8-3 - Apply upstream bugfix patch 27170 * Fri Feb 10 2006 Jesse Keating - 4:5.8.8-2.1 - bump again for double-long bug on ppc(64) * Fri Feb 10 2006 Jason Vas Dias - 4:5.8.8-2 - Rebuild again - Debian released 5.8.8 patches today; apply only relevant difference: 03_fix_net_nntp : fix precedence in Net::NNTP::article from Brendan O'Dea * Mon Feb 06 2006 Jason Vas Dias - 4:5.8.8-1.2 - Rebuild with new gcc, glibc, and glibc-kernheaders * Fri Feb 03 2006 Jason Vas Dias - 4:5.8.8-1.1 - Rebuild with new gcc and glibc * Wed Feb 01 2006 Jason Vas Dias - 4:5.8.8-1 - Upgrade to new upstream release 5.8.8, officially released today * Tue Jan 31 2006 Jason Vas Dias - 3:5.8.8-0.1_RC1 - fix bug 178343: h2ph must include cpp "predefined macros" in _h2ph_pre.ph - Add perl(:MODULE_COMPAT_5.8.8) to Provides - Fix perlbug patch * Fri Jan 20 2006 Jason Vas Dias - 3:5.8.8-0_RC1 - Upgrade to new upstream release candidate 5.8.8-RC1 * Wed Dec 14 2005 Jason Vas Dias - 3:5.8.7-8.1 - Updated upstream patches for CVE-2005-3962: 26322 , 26331, 26333 * Thu Dec 08 2005 Jason Vas Dias - 3:5.8.7-8 - Apply upstream patches 26283 and 26284 : complete, revised fixes for CVE-2005-3962 and CVE-2005-3912 and "Sys::Syslog security vulnerabilities" issues. - Fix bug 136009 / MakeMaker LD_RUN_PATH issue: restore previous default Red Hat behavior of removing the MakeMaker generated LD_RUN_PATH setting from the link command . Document this removal, as it contravenes upstream default behavior, and provide a USE_MM_LD_RUN_PATH MakeMaker member to enable use of the MakeMaker generated LD_RUN_PATH . * Thu Dec 01 2005 Jason Vas Dias - 3:5.8.7-0.8 - fix bug 174684 / CVE-2005-3962: sprintf integer overflow vulnerability backport upstream patch #26240 * Wed Nov 09 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 136009: restore MakeMaker support for LD_RUN_PATH, while removing empty LD_RUN_PATH * Tue Nov 08 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 172739: upstream bug 36521 : deep recursion and segfault in CGI::Carp::warn with 'use diagnostics' : applied patch 25160. - fix CAN-2004-0976: insecure use of temp files (ala Debian) * Mon Nov 07 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 172587: apply upstream patches 26009, 26011 * Thu Nov 03 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 172396 / upstream bug 26136: insert tzset() call before localtime_r() calls * Wed Nov 02 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 172336 / upstream bug 37056: reentr ERANGE realloc recursion * Tue Nov 01 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 172236 : missing C standard headers - use gcc4's '-print-search-path' option in h2ph * Tue Oct 25 2005 Jason Vas Dias - 3:5.8.7-0.6 - fix bug 171111 : define ioctl length macro IOCPARM_LEN(x) macro to be _IOC_SIZE(x), not 256 - upstream bug #37535 raised. - provide 'perl_debugging' .spec file option to enable -DDEBUGGING and disable stripping / debuginfo generation - default: 0 * Sun Oct 09 2005 Warren Togami - 3:5.8.7-0.4 - rebuild for db4 (#170235) * Mon Sep 05 2005 Warren Togami - 3:5.8.7-0.3 - convert docs to UTF-8 (#140871) * Sat Sep 03 2005 Warren Togami - 3:5.8.7-0.2 - scriptdir to /usr/bin (#167205) * Sun Aug 28 2005 Warren Togami - 3:5.8.7-0.1 - patch12 from Marius Feraru (#165907) TODO: patch11, patch26 and patch27 clash and need verification - Build without -DDEBUGGING (#156113) * Sun Aug 14 2005 Jose Pedro Oliveira - 3:5.8.7-0 - 5.8.7 - Dropped the CGI.pm update patches (patch25 and patch29). * Fri Aug 12 2005 Jose Pedro Oliveira - 3:5.8.6-17 - Don't remove the core modules: Filter::Util::Call, Filter::Simple, and Time::HiRes. - Obsoletes perl-{Filter,Filter-Simple,Time-HiRes}. * Tue Aug 9 2005 Jose Pedro Oliveira - 3:5.8.6-16 - Reformatted the specfile. - Added the Source0 URL. - Dropped the MANIFEST.all file for the perl package. - Dropped the MANIFEST.suidperl file for the suidperl subpackage. * Wed May 18 2005 Warren Togami - 3:5.8.6-15 - remove unused /tmp/MANIFEST.all (#151801) * Tue May 17 2005 Warren Togami - 3:5.8.6-14 - CGI.pm 3.10 fixes mod_perl problems (#158036) * Sun May 15 2005 Warren Togami - 3:5.8.6-13 - Better patch for FindBin.pm (#127023#c37) * Sat May 14 2005 Jose Pedro Oliveira - 3:5.8.6-12 - New findbin-selinux patch: it now passes the FindBin.t tests (patch28 replaces patch23). #118877 #127023 - Remove 5.8.2 ABI compat (#154295 comments 6 and 7). * Thu Apr 28 2005 Ville Skytt? - 3:5.8.6-10 - Apply fixes for CAN-2004-0452, CAN-2005-0155 and CAN-2005-0156 (#156128). * Tue Apr 26 2005 Warren Togami - 3:5.8.6-7 - Updating CGI.pm from version 3.05 to 3.08 (mod_perl 2.0.0 RC5). (#155839) * Wed Apr 20 2005 Jose Pedro Oliveira - 3:5.8.6-6 - FCGI is not provided by perl (#148847). - Drop the '.1' suffix from the perl-suidperl subpackage. * Thu Mar 17 2005 Jason Vas Dias - 3:5.8.6-5 - bug 151127: fix to use libresolv instead of libbind (perl-5.8.6-libresolv.patch). * Tue Mar 8 2005 Chip Turner - 3:5.8.6-4 - add patch to put site_perl and vendor_perl before core perl dirs, to allow for overriding modules * Sat Jan 29 2005 Warren Togami - 3:5.8.6-3 - bugzilla: 127025, fix strip warnings * Tue Jan 18 2005 Chip Turner - 3:5.8.6-2 - bugzilla: 145448, fix invalid utf8 in changelog * Tue Jan 18 2005 Chip Turner - 3:5.8.6-1 - bugzilla: 145447, add 5.8.5 to perlmodcompat list * Mon Jan 17 2005 Chip Turner - 3:5.8.6-1 - update to 5.8.6 * Wed Dec 1 2004 Chip Turner 3:5.8.5-13 - rebuild * Wed Dec 1 2004 Chip Turner 3:5.8.5-11 - bugzilla: 140563, nptl doesn't act like linuxthreads; threads have no PIDs * Thu Nov 11 2004 Jeff Johnson 3:5.8.5-10 - rebuild against db-4.3.21. * Tue Oct 12 2004 Jose Pedro Oliveira - Corrected the license information (missing GPL). - Added the URL tag. - Removed empty .bs files. - Eliminated several strip generated messages (bug 127025). - Corrected problems mentioned in bug 120772 (updated Ville Skytta) * Tue Oct 12 2004 Chip Turner - bugzilla: 135303, add more missing 5.8.4 paths * Mon Oct 11 2004 Tim Waugh - Build requires groff (bug #135101). * Tue Oct 5 2004 Chip Turner 3:5.8.5-7 - update perlbug patch to strip build date as well * Mon Aug 23 2004 Chip Turner 3:5.8.5-2 - fix conflicting file when building on x86_64 and i386 * Sat Jul 24 2004 Chip Turner 3:5.8.5-1 - Add Provides: Carp::Heavy to fix new dep error (bz 128507) * Thu Jul 22 2004 Chip Turner 3:5.8.5-1 - update to 5.8.5 * Mon Jun 28 2004 Chip Turner 3:5.8.4-1 - update to 5.8.4, remove patch 8 * Tue Jun 15 2004 Elliot Lee - rebuilt * Thu Apr 15 2004 Chip Turner 3:5.8.3-18 - add patch to fix empty RPATH issue on perl module compile * Sat Apr 03 2004 Colin Walters 3:5.8.3-17 - Apply patch to fix FindBin module when access to cwd is disallowed, should solve the MRTG/SELinux cron spam issue * Tue Mar 23 2004 Chip Turner 3:5.8.3-14 - make sure multilib boxes also own the entries in @INC that are in /usr/lib, not just %%_libdir * Tue Mar 9 2004 Chip Turner 3:5.8.3-%%{perlrel}.1 - fix i386-specifics in %%install to arch generic * Tue Mar 02 2004 Elliot Lee - rebuilt * Wed Feb 25 2004 Chip Turner 3:5.8.3-10 - add perl(:MODULE_COMPAT_*) provides; make sure all of @INC is owned by perl package * Thu Feb 19 2004 Chip Turner 3:5.8.3-8 - rebuild * Thu Feb 19 2004 Chip Turner 3:5.8.3-7.9.rhl9 - rebuild patch for perl 5.8.4). * Thu Feb 19 2004 Chip Turner 3:5.8.3-7.10.fc1 - rebuild * Sun Feb 15 2004 Chip Turner 3:5.8.3-6 - fix very broken @INC calculations with slightly less broken @INC calculations (not perfectly handled but the result is correct) - fix broken -Dsitearch declaration * Fri Feb 13 2004 Elliot Lee - rebuilt * Wed Jan 28 2004 Chip Turner 3:5.8.3-5 - update incpush patch to better handle multilib * Fri Jan 23 2004 Chip Turner 3:5.8.3-2 - add a dependency filter on perl(Tie::RangeHash) * Thu Jan 22 2004 Chip Turner 3:5.8.3-7 - upgrade to 5.8.3 * Mon Dec 15 2003 Chip Turner 3:5.8.2-7 - fix @INC so that all dirs go into it, not just those that exist at buildtime in the build system * Sat Dec 13 2003 Jeff Johnson 3:5.8.2-4 - rebuild against db-4.2.52. * Sun Dec 7 2003 Ville Skytt? - 3:5.8.2-3 - Own site and vendor auto directories (#73970). * Wed Dec 3 2003 Chip Turner 3:5.8.2-2 - upgrade to 5.8.2 * Fri Oct 31 2003 Chip Turner 3:5.8.1-92 - remove Vendor and Distribution macros from specfile (#108567) * Wed Oct 15 2003 Chip Turner 3:5.8.1-92 - add srand on fork patch from upstream, as well as test case * Mon Oct 13 2003 Jeff Johnson 3:5.8.1-91.1 - rebuild against db-4.2.42. * Thu Sep 25 2003 Chip Turner 3:5.8.1-91 - perl 5.8.1 final * Mon Sep 22 2003 Chip Turner 3:5.8.1-90.rc5.3 - ensure inc_version_list is always set properly * Mon Sep 22 2003 Chip Turner - update to RC5 * Wed Aug 20 2003 Chip Turner 3:5.8.1-90.rc4.2 - rebuild * Wed Aug 6 2003 Chip Turner - bugzilla 101767, make sure threads.so links directly to -lpthread * Fri Aug 1 2003 Chip Turner 3:5.8.1-90.rc2.1 - RC4 - remove perl-5.8.0-fhs.patch since it is integrated now - remove perl-5.8.0-Safe2.09.patch, unnecessary now * Fri Jul 11 2003 Chip Turner 3:5.8.1-90.rc2.1 - rc2 snapshot * Thu Jul 10 2003 Chip Turner 3:5.8.0-90.rc1 - upgrade to 5.8.1 RC1 * Mon Jul 7 2003 Chip Turner 3:5.8.0-89.pre%%{PRELEVEL}.0 - integrate another pre-5.8.1 release * Wed Jun 04 2003 Elliot Lee - rebuilt * Mon May 19 2003 Chip Turner 3:5.8.0-89.pre%%{PRELEVEL}.0 - bump epoch since we went from perl 5.8.1-pre to 5.8.0-pre (ie, changed what version perl thought of itself as) * Mon May 5 2003 Chip Turner 2:5.8.1-0.pre%%{PRELEVEL}.3 - rebuild * Thu May 1 2003 Chip Turner - bump for rebuilg * Sun Apr 27 2003 Chip Turner 2:5.8.1-0.pre%%{PRELEVEL}.1 - fix the fix for RPM_BUILD_ROOT substitution * Tue Apr 22 2003 Chip Turner 2:5.8.1-0.pre%%{PRELEVEL}.3 - fix Config.pm; lost when h2ph changes made * Thu Apr 17 2003 Chip Turner 2:5.8.1-0.pre%%{PRELEVEL} - move to latest snapshot, 19261 * Tue Feb 18 2003 Chip Turner - fix MANIFEST.DB_File handling for #83410; problem was unsubstituted %%{_libdir} that crept in with multilib * Tue Feb 18 2003 Bill Nottingham 5.8.0-87 - clean up backup files from patches (#82838) * Wed Feb 05 2003 Elliot Lee 5.8.0-86 - Fix up multilib handling to use multilib_64_archs macro, add ppc64. - Patch100 probably makes sense on all archs, and ifarch'd patches are Bad(tm). * Mon Jan 27 2003 Chip Turner - version the Obsoleted on perl-NDBM_File so users can install newer - change the Obsoletes on NDBM_File to a Conflicts ones than what shipped with 7.3, yet still keep anaconda happy * Wed Jan 22 2003 Tim Powers - rebuilt * Thu Jan 9 2003 Chip Turner - rebuild * Sat Jan 4 2003 Jeff Johnson 5.8.0-82 - use internal dep generator. * Thu Jan 2 2003 Chip Turner - fix issue with -Dpager in Pod::Perldoc.pm to properly respect setting once more * Tue Dec 31 2002 Chip Turner - add rpath fix to prevent building perl from using installed system perl - massive re-integration of upstream patches to come to common basis (head of perl-maint branch) * Mon Dec 16 2002 Chip Turner - rebuild * Sun Dec 15 2002 Chip Turner - add numerous upstream patches to fix utf8/perlio issues - upgrade Storable, Safe, and Encoding to latest CPAN versions * Thu Nov 7 2002 Chip Turner - multilib support when building noarch perl modules - integrate upstream bugfix patches * Tue Sep 10 2002 Chip Turner - integrate patch for /usr/lib64 instead of /usr/lib from Than Ngo * Mon Sep 9 2002 Chip Turner - integrate s390/s390x patch from Florian La Roche * Sun Sep 1 2002 Chip Turner - fix pager issues; default to /usr/bin/less -isr - more work on pager bug (72125) * Thu Aug 29 2002 Chip Turner - add a few new directories to h2ph to produce better .ph files * Thu Aug 15 2002 Chip Turner - change from lynx to links in CPAN.pm * Tue Aug 6 2002 Chip Turner - automated release bump and build - remove Filter packages and use CPAN ones * Fri Jul 19 2002 Chip Turner - move to final perl 5.8.0, huzzah! * Tue Jul 16 2002 Chip Turner - update CPAN, CGI, and DB_File versions; obsolete perl-libnet - libnet.cfg supplied, default to passive ftp in all cases * Tue Jun 18 2002 Chip Turner - add patch to ensire libperl.so is linked properly * Mon May 20 2002 Nalin Dahyabhai - always build with -fPIC * Thu May 9 2002 Jeff Johnson - rebuild in rawhide * Sun Mar 31 2002 Chip Turner - split suidperl back out (bug #62215) * Tue Mar 26 2002 Chip Turner - restructuring of some directories, alteration of @INC * Thu Dec 20 2001 Chip Turner - remove ndbm completely * Sun Dec 16 2001 Chip Turner - make rpmlint happy, split out NDBM_File, clean up other spots - stopped doing grep -v etc in favor of custom script * Wed Dec 12 2001 Chip Turner - cleaning up of ia64 issues, as well as compatibility with gcc 3.1 and glibc 2.2.4 * Mon Sep 24 2001 Chip Turner - changing building of extra modules out of the core perl rpm * Mon Sep 17 2001 Chip Turner - upgrade to 5.6.1, added old INC dirs to maintain compat * Fri Mar 23 2001 Preston Brown - bzip2 source, save some space. * Thu Dec 7 2000 Crutcher Dunnavant - initial rebuild for 7.1 * Tue Sep 12 2000 Bill Nottingham - fix dependencies on ia64/sparc64 * Mon Aug 7 2000 Nalin Dahyabhai - replace the deprecated MD5 with Digest::MD5 (has to be here for cleanfeed) - obsolete: perl-Digest-MD5 - use syslog instead of mail to report possible attempts to break into suidperl - force syslog on at build-time * Mon Jul 31 2000 Nalin Dahyabhai - add Owen's fix for #14779/#14863 - specify cc=%%{__cc}; continue to let cpp sort itself out - switch shadow support on (#8646) - release 7 * Tue Jul 18 2000 Nalin Dahyabhai - strip buildroot from perl pods (#14040) - release 6 * Wed Jul 12 2000 Prospector - automatic rebuild (release 5) * Wed Jun 21 2000 Preston Brown - don't require tcsh to install, only to build - release 4 * Mon Jun 19 2000 Nalin Dahyabhai - rebuild against new db3 package - release 3 * Sat Jun 17 2000 Nalin Dahyabhai - disable 64-bit file support - change name of package that Perl expects gcc to be in from "egcs" to "gcc" - move man pages to /usr/share via hints/linux.sh and MM_Unix.pm - fix problems prefixifying with empty prefixes - disable long doubles on sparc (they're the same as doubles anyway) - add an Epoch to make sure we can upgrade from perl-5.00503 - release 2 * Thu Mar 23 2000 Bernhard Rosenkraenzer - 2.6.0 * Wed Feb 02 2000 Cristian Gafton - fix description * Fri Jan 14 2000 Jeff Johnson - add provides for perl modules (from kestes at staff.mail.com). * Mon Oct 04 1999 Cristian Gafton - fix the %%install so that the MD5 module gets actually installed correctly * Mon Aug 30 1999 Cristian Gafton - make sure the package builds even when we don't have perl installed on the system * Fri Aug 06 1999 Cristian Gafton - merged with perl-MD5 - get rid of the annoying $RPM_BUILD_ROOT paths in the installed tree * Mon Jul 26 1999 Cristian Gafton - do not link anymore against the system db library (and make each module link against it separately, so that we can have Berkeley db1 and db2 mixed up) * Wed Jun 16 1999 Cristian Gafton - use wildcards for files in /usr/bin and /usr/man * Tue Apr 06 1999 Cristian Gafton - version 5.00503 - make the default man3 install dir be release independent - try to link against db1 to preserve compatibility with older databases; abandoned idea because perl is too broken to allow such an easy change (hardcoded names *everywhere* !!!) * Sun Mar 21 1999 Cristian Gafton - auto rebuild in the new build environment (release 3) * Thu Jan 07 1999 Cristian Gafton - guilty of the inlined Makefile in the spec file - adapted for the arm build * Wed Sep 09 1998 Preston Brown - added newer CGI.pm to the build - changed the version naming scheme around to work with RPM * Sun Jul 19 1998 Jeff Johnson - attempt to generate *.ph files reproducibly * Mon Jun 15 1998 Jeff Johnson - update to 5.004_04-m4 (pre-5.005 maintenance release) * Tue Jun 12 1998 Christopher McCrory - added a patch to correct the .ph constructs unless defined (foo) to read unless(defined(foo)) * Thu May 07 1998 Prospector System - translations modified for de, fr, tr * Tue Mar 10 1998 Cristian Gafton - fixed strftime problem * Sun Mar 08 1998 Cristian Gafton - added a patch to fix a security race - do not use setres[ug]id - those are not implemented on 2.0.3x kernels * Mon Mar 02 1998 Cristian Gafton - upgraded to 5.004_04 - 5.004_01 had some nasty memory leaks. - fixed the spec file to be version-independent * Fri Dec 05 1997 Erik Troan - Config.pm wasn't right do to the builtrooting * Mon Oct 20 1997 Erik Troan - fixed arch-specfic part of spec file * Sun Oct 19 1997 Erik Troan - updated to perl 5.004_01 - users a build root * Thu Jun 12 1997 Erik Troan - built against glibc * Tue Apr 22 1997 Erik Troan - Incorporated security patch from Chip Salzenberg * Fri Feb 07 1997 Erik Troan - Use -Darchname=i386-linux - Require csh (for glob) - Use RPM_ARCH during configuration and installation for arch independence -------------- next part -------------- -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rc040203 at freenet.de Fri Mar 30 17:11:48 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 30 Mar 2007 19:11:48 +0200 Subject: New perl spec file In-Reply-To: References: Message-ID: <1175274708.24401.294.camel@mccallum.corsepiu.local> On Wed, 2007-03-28 at 15:33 -0400, Robin Norwood wrote: > Hi, > > Sorry for the delay, but here's a new perl spec file including Ralf and > Tom's changes, removing the Requires: perl-devel, and a couple of minor > cleanups from me. > > It seems to build, except on s390... I'll look into that. > > Comments? Some remarks without actually having tried it yet: - "sh Configure ..." I'd prefer "/bin/sh Configure" - There are several places where a hard-coded "/usr/bin" is used At least those which refer to files currently being built should probably be %{_bindir} - there are hard-coded "/usr/lib"'s I think, these should be "%{_prefix}/lib" Ralf From rnorwood at redhat.com Fri Mar 30 17:26:11 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 30 Mar 2007 13:26:11 -0400 Subject: New perl spec file In-Reply-To: <1175274708.24401.294.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Fri, 30 Mar 2007 19:11:48 +0200") References: <1175274708.24401.294.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Wed, 2007-03-28 at 15:33 -0400, Robin Norwood wrote: >> Hi, >> >> Sorry for the delay, but here's a new perl spec file including Ralf and >> Tom's changes, removing the Requires: perl-devel, and a couple of minor >> cleanups from me. >> >> It seems to build, except on s390... I'll look into that. >> >> Comments? > > Some remarks without actually having tried it yet: > > - "sh Configure ..." > I'd prefer "/bin/sh Configure" > > - There are several places where a hard-coded "/usr/bin" is used > At least those which refer to files currently being built should > probably be %{_bindir} > > - there are hard-coded "/usr/lib"'s > I think, these should be "%{_prefix}/lib" Alright, looking at fixing all three of these now. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From bugzilla at redhat.com Fri Mar 30 20:03:35 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 30 Mar 2007 16:03:35 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200703302003.l2UK3ZBO025679@bugzilla.redhat.com> Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: EPEL branches: a couple of perl packages from fedora.us https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232481 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From jpo at di.uminho.pt 2007-03-30 16:03 EST ------- The packages are already available in the EPEL repo: http://download.fedora.redhat.com/pub/epel/ -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. From rc040203 at freenet.de Sat Mar 31 04:52:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 31 Mar 2007 06:52:52 +0200 Subject: New perl spec file In-Reply-To: References: Message-ID: <1175316772.24401.339.camel@mccallum.corsepiu.local> On Wed, 2007-03-28 at 15:33 -0400, Robin Norwood wrote: > Hi, > > Sorry for the delay, but here's a new perl spec file including Ralf and > Tom's changes, removing the Requires: perl-devel, and a couple of minor > cleanups from me. > > It seems to build, except on s390... I'll look into that. > > Comments? It doesn't work. The epochs on dependencies on "perl" inside of sub-packages are wrong. E.g.: # rpm -q --requires -p perl-CPAN-1.76_02-16.i386.rpm ... perl = 0:5.8.8-16 ... # rpm -q --provides -p perl-5.8.8-16.i386.rpm ... perl = 4:5.8.8-16 ... This causes all kind of dependency breakages in yum. AFAIS, you seem to have missed the %{epoch} related Requires having been contained in my latest *.spec. Ralf From rc040203 at freenet.de Sat Mar 31 05:22:33 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 31 Mar 2007 07:22:33 +0200 Subject: New perl spec file In-Reply-To: <1175316772.24401.339.camel@mccallum.corsepiu.local> References: <1175316772.24401.339.camel@mccallum.corsepiu.local> Message-ID: <1175318553.24401.351.camel@mccallum.corsepiu.local> On Sat, 2007-03-31 at 06:52 +0200, Ralf Corsepius wrote: > On Wed, 2007-03-28 at 15:33 -0400, Robin Norwood wrote: > > Hi, > > > > Sorry for the delay, but here's a new perl spec file including Ralf and > > Tom's changes, removing the Requires: perl-devel, and a couple of minor > > cleanups from me. > > > > It seems to build, except on s390... I'll look into that. > > > > Comments? > It doesn't work. > > The epochs on dependencies on "perl" inside of sub-packages are wrong. > > E.g.: > # rpm -q --requires -p perl-CPAN-1.76_02-16.i386.rpm > ... > perl = 0:5.8.8-16 > ... > > # rpm -q --provides -p perl-5.8.8-16.i386.rpm > ... > perl = 4:5.8.8-16 > ... > > This causes all kind of dependency breakages in yum. > > AFAIS, you seem to have missed the %{epoch} related Requires having been > contained in my latest *.spec. Scratch this sentence - I was wrong. You added Requires: perl = %{epoch}:%{perl_version}-%{release} to subpackages' %package. This breaks if a subpackage uses a different Epoch as the main packages, for example this: ... %package Test-Harness Summary: Run Perl standard test scripts with statistics Group: Development/Languages Epoch: 0 Version: 2.56 Requires: perl-devel Requires: perl = %{epoch}:%{perl_version}-%{release} ... At the time, rpm processes the %{epoch} inside of the "Requires: perl =...", %{epoch} contains the "0" from the "Epoch: 0" line above and doesn't contain the global epoch anymore. A brute-force approach to work-around this would be to add a global %define perl_epoch 4 at the beginning of the *.spec and to replace all references to the main perl package's Epoch (%{epoch}) with %{perl_epoch} The patch below implements this approach. Ralf -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-spec-16.1.diff Type: text/x-patch Size: 2943 bytes Desc: not available URL: