From bugzilla at redhat.com Tue May 1 16:36:09 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 1 May 2007 12:36:09 -0400 Subject: [Bug 238581] New: careless use of gethostbyname() in Socket.xs 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=238581 Summary: careless use of gethostbyname() in Socket.xs Product: Fedora Core Version: fc5 Platform: All URL: http://rt.perl.org/rt3/Public/Bug/Display.html?id=42844 OS/Version: Linux Status: NEW Severity: low Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: peak at argo.troja.mff.cuni.cz QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: Socket::inet_aton() does not the length of data returned by gethostbyname() before copying it. See the link to PerlBug for details. Version-Release number of selected component (if applicable): 5.8.8-4 (other versions are affected as well) How reproducible: Easily when you LD_PRELOAD a broken implementation of gethostbyname(). :) -- 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 Tue May 1 21:14:06 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 1 May 2007 17:14:06 -0400 Subject: [Bug 237594] Upgrade to SVK 2.0.1 In-Reply-To: Message-ID: <200705012114.l41LE6la028690@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: Upgrade to SVK 2.0.1 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237594 dearfrankg at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dearfrankg at gmail.com ------- Additional Comments From dearfrankg at gmail.com 2007-05-01 17:13 EST ------- I would like to get this rpm into FC6 also. 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 dave at dave.org.uk Wed May 2 15:23:11 2007 From: dave at dave.org.uk (Dave Cross) Date: Wed, 02 May 2007 16:23:11 +0100 Subject: Catalyst / DBIx::Class / SQL::Translator Message-ID: <4638ACDF.8050003@dave.org.uk> Last September there was some talk on this about getting Catalyst (and therefore DBIx::Class and SQL::Translator) into Extras. Was there any progress on this? And if people are help up through lack of resources, is there anything I can do to help? Cheers, Dave... From cweyl at alumni.drew.edu Wed May 2 15:48:40 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 2 May 2007 08:48:40 -0700 Subject: Catalyst / DBIx::Class / SQL::Translator In-Reply-To: <4638ACDF.8050003@dave.org.uk> References: <4638ACDF.8050003@dave.org.uk> Message-ID: <7dd7ab490705020848v5ad6e21dlc52dd7a98ed604c5@mail.gmail.com> On 5/2/07, Dave Cross wrote: > > Last September there was some talk on this about getting Catalyst (and > therefore DBIx::Class and SQL::Translator) into Extras. > > Was there any progress on this? And if people are help up through lack > of resources, is there anything I can do to help? Hey Dave -- I've been working on getting the "base" Catalyst framework into extras over the last couple weeks or so. Right now, it's just a matter of Catalyst-Devel and Catalyst-Runtime (and all their deps), you can find the review bugs all under Catalyst-Devel's dependency tree: https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=238238 Certainly reviews will help get these base modules in; if there are additional Catalyst modules you'd like to see in Fedora (e.g. perhaps Task::Catalyst::Tutorial? ) just make sure they're marked as depending on Catalyst-Runtime (bug 238211). That way they'll show up in the dependency tree there as well... -Chris -- Chris Weyl Ex astris, scientia From rc040203 at freenet.de Wed May 2 15:47:59 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 02 May 2007 17:47:59 +0200 Subject: Catalyst / DBIx::Class / SQL::Translator In-Reply-To: <4638ACDF.8050003@dave.org.uk> References: <4638ACDF.8050003@dave.org.uk> Message-ID: <1178120879.4283.311.camel@mccallum.corsepiu.local> On Wed, 2007-05-02 at 16:23 +0100, Dave Cross wrote: > Last September there was some talk on this about getting Catalyst (and > therefore DBIx::Class and SQL::Translator) into Extras. > > Was there any progress on this? And if people are help up through lack > of resources, is there anything I can do to help? Check out bugzilla. Chris Weyl has been busy committing review requests, several of them still awaiting review (hint!) Ralf From bugzilla at redhat.com Fri May 4 22:50:45 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 4 May 2007 18:50:45 -0400 Subject: [Bug 237594] Upgrade to SVK 2.0.1 In-Reply-To: Message-ID: <200705042250.l44MojPg008127@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: Upgrade to SVK 2.0.1 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237594 Bug 237594 depends on bug 232018, which changed state. Bug 232018 Summary: Review Request: perl-YAML-Syck - Fast, lightweight YAML loader and dumper https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=232018 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 cweyl at alumni.drew.edu Fri May 4 23:04:31 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 4 May 2007 16:04:31 -0700 Subject: Catalyst status... Message-ID: <7dd7ab490705041604i56483d93tf2f466ec2a20a5fe@mail.gmail.com> So we're making good progress with the base Catalyst packages: all of the packages Catalyst::Runtime depends on have been reviewed and have been imported/built; in addition to Catalyst::Runtime, there are three other packages which need to be reviewed before Catalyst::Devel can be. https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?id=238238 Beyond that, I suspect the next course of action would be to package up the outstanding deps for Task::Catalyst::Tutorial... I've put the output of this distro's deps (from my hacked version of cpanspec) up at: http://fedoraproject.org/wiki/Perl/Catalyst. If anyone wants to help (*cough* recent emails *cough*), reviews are always good; packaging up parts of Task::Catalyst::Tutorial and submitting them would also be good (as I can help with reviews then). Anyways, enjoy :) -Chris -- Chris Weyl Ex astris, scientia From cweyl at alumni.drew.edu Fri May 4 23:12:34 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 4 May 2007 16:12:34 -0700 Subject: Test::Pod::Coverage tests... In-Reply-To: <7dd7ab490704271018t6a2ef883q88e6944a7e54c1c9@mail.gmail.com> References: <7dd7ab490704271018t6a2ef883q88e6944a7e54c1c9@mail.gmail.com> Message-ID: <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> On 4/27/07, Chris Weyl wrote: > My opinion is that we ought to not mandate the use of Pod coverage > tests, simply because for our purposes it doesn't really matter what > their result is. If they're present, we should conditionalize the > tests (e.g. %_with_pod_tests magic or some such), but not insist on > them by default. So, to follow up to myself here, given the lack of comments I'm inclined to approve 237883 without insisting on Test::Pod::Coverage due to T::P::C not testing the _functionality_ of the package. One last chance to scream :) -Chris -- Chris Weyl Ex astris, scientia From bugzilla at redhat.com Fri May 4 23:30:18 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 4 May 2007 19:30:18 -0400 Subject: [Bug 239118] New: perl-YAML-Syck fails to build due to missing perl-Devel-Leak in ppc64 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=239118 Summary: perl-YAML-Syck fails to build due to missing perl-Devel- Leak in ppc64 Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-YAML-Syck 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 Tracker bug blocking PPC64MissingDeps, as detailed on fedora-maintainers. perl-YAML-Syck fails to build in devel due to a missing dep on perl-Devel-Leak. -- 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 May 4 23:30:30 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 4 May 2007 19:30:30 -0400 Subject: [Bug 238907] PPC64 builds fail due to missing deps In-Reply-To: Message-ID: <200705042330.l44NUU02009100@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: PPC64 builds fail due to missing deps Alias: PPC64MissingDeps https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=238907 cweyl at alumni.drew.edu changed: What |Removed |Added ---------------------------------------------------------------------------- BugsThisDependsOn| |239118 -- 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 tcallawa at redhat.com Sat May 5 02:50:47 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Fri, 04 May 2007 21:50:47 -0500 Subject: Test::Pod::Coverage tests... In-Reply-To: <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> References: <7dd7ab490704271018t6a2ef883q88e6944a7e54c1c9@mail.gmail.com> <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> Message-ID: <1178333447.3992.4.camel@localhost.localdomain> On Fri, 2007-05-04 at 16:12 -0700, Chris Weyl wrote: > On 4/27/07, Chris Weyl wrote: > > My opinion is that we ought to not mandate the use of Pod coverage > > tests, simply because for our purposes it doesn't really matter what > > their result is. If they're present, we should conditionalize the > > tests (e.g. %_with_pod_tests magic or some such), but not insist on > > them by default. > > So, to follow up to myself here, given the lack of comments I'm > inclined to approve 237883 without insisting on Test::Pod::Coverage > due to T::P::C not testing the _functionality_ of the package. One > last chance to scream :) I'd rather include it. Simply because the Pod coverage tests don't test anything useful today doesn't mean they won't in the future, and by letting it slide now, we increase the chance that it will slide by unnoticed in the future. But I'm not really torn up either way. I'd rather say "test everything, useful or not" to make sure we cover everything than trying to judge usefulness of tests on a test by test basis. Blanket policies help me sleep easier at night. :) ~spot From bugzilla at redhat.com Sun May 6 11:16:14 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 07:16:14 -0400 Subject: [Bug 239219] New: perl-PAR-Dist-0.22 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=239219 Summary: perl-PAR-Dist-0.22 is available Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-PAR-Dist 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-PAR-Dist-0.22 is already available. Repo version is 0.21. 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 May 6 13:40:35 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 09:40:35 -0400 Subject: [Bug 239219] perl-PAR-Dist-0.22 is available In-Reply-To: Message-ID: <200705061340.l46DeZ6m003835@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-PAR-Dist-0.22 is available https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239219 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE ------- Additional Comments From ville.skytta at iki.fi 2007-05-06 09:40 EST ------- Done in devel. -- 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 May 6 15:00:19 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 11:00:19 -0400 Subject: [Bug 237612] WWW::Bugzilla fails to fetch bug In-Reply-To: Message-ID: <200705061500.l46F0JDZ005553@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: WWW::Bugzilla fails to fetch bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237612 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED ------- Additional Comments From jpo at di.uminho.pt 2007-05-06 11:00 EST ------- Chris, WWW::Bugzilla 0.9 is already available in the FE-6 repository. Could you check if this version resolves your problem? 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 Sun May 6 15:29:01 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 11:29:01 -0400 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200705061529.l46FT1OS006168@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 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|normal |medium jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |ASSIGNED Keywords| |Reopened Resolution|NEXTRELEASE | ------- Additional Comments From jpo at di.uminho.pt 2007-05-06 11:28 EST ------- (In reply to comment #39) > ok, looks like they both built successfully. Finally done with this bug. :-) Not yet ;) You haven't built it for development (Fedora 7). 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 Sun May 6 16:04:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 12:04:26 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200705061604.l46G4QrK006873@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|CLOSED |ASSIGNED Keywords| |Reopened Resolution|NEXTRELEASE | Flag|fedora-cvs+ |fedora-cvs? ------- Additional Comments From jpo at di.uminho.pt 2007-05-06 12:04 EST ------- ======================= Package Name: perl-Text-Template Short Description: Expand template text with embedded Perl Owners: jpo at di.uminho.pt Branches: EL-4 EL-5 InitialCC: fedora-perl-devel-list at redhat.com ======================= Package Name: perl-Pod-Coverage Short Description: Checks if the documentation of a module is comprehensive Owners: jpo at di.uminho.pt Branches: EL-4 EL-5 InitialCC: fedora-perl-devel-list at redhat.com ======================= Package Name: perl-Test-Pod-Coverage Short Description: POD documentation coverage checker Owners: jpo at di.uminho.pt Branches: EL-4 EL-5 InitialCC: fedora-perl-devel-list at redhat.com ======================= Package Name: perl-Error Short Description: Error Perl module Owners: jpo at di.uminho.pt Branches: EL-5 InitialCC: fedora-perl-devel-list at redhat.com ======================= Package Name: perl-Cache-Cache Short Description: Cache-Cache module for perl Owners: jpo at di.uminho.pt Branches: 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 Sun May 6 20:19:32 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 16:19:32 -0400 Subject: [Bug 239241] New: perl-Pod-Strip: missing dependency on perl(Pod::Simple) 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=239241 Summary: perl-Pod-Strip: missing dependency on perl(Pod::Simple) Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-Pod-Strip AssignedTo: jpo at di.uminho.pt ReportedBy: ville.skytta at iki.fi QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com perl-Pod-Strip 1.02-1.fc6 is missing a dependency on perl(Pod::Simple) - rpmbuild doesn't catch dependencies from "use base ..." statements: $ perl -MPod::Strip -e '' Base class package "Pod::Simple" is empty. (Perhaps you need to 'use' the module which defines that package first.) at /usr/lib/perl5/vendor_perl/5.8.8/Pod/Strip.pm line 6 BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/Pod/Strip.pm line 6. Compilation failed in require. BEGIN failed--compilation aborted. -- 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 May 6 20:24:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 16:24:52 -0400 Subject: [Bug 239241] perl-Pod-Strip: missing dependency on perl(Pod::Simple) In-Reply-To: Message-ID: <200705062024.l46KOqv2013501@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-Pod-Strip: missing dependency on perl(Pod::Simple) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239241 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |239193 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 Sun May 6 21:36:31 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 17:36:31 -0400 Subject: [Bug 239241] perl-Pod-Strip: missing dependency on perl(Pod::Simple) In-Reply-To: Message-ID: <200705062136.l46LaVRc015138@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-Pod-Strip: missing dependency on perl(Pod::Simple) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239241 jpo at di.uminho.pt changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |CURRENTRELEASE Fixed In Version| |1.02-2 ------- Additional Comments From jpo at di.uminho.pt 2007-05-06 17:36 EST ------- New package - perl-Pod-Strip-1.02-2 - built for FC-5, FC-6, and F-7. Specfile changelog: perl(Pod::Simple) added to the requirement list. -- 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 tcallawa at redhat.com Sun May 6 23:36:27 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Sun, 06 May 2007 18:36:27 -0500 Subject: Bugzilla 3.0 Perl Requirements In-Reply-To: <20070204162857.1AD9B8C8001@help.trusthosting.net> References: <20070204162857.1AD9B8C8001@help.trusthosting.net> Message-ID: <1178494587.3661.3.camel@localhost.localdomain> On Sun, 2007-02-04 at 08:28 -0800, Max Kanat-Alexander wrote: > Hey folks. Just wanted to let you know that Bugzilla 3.0 (which > should be out soon) has a few perl pre-reqs that aren't in Extras. One > of them is required: > > Email-Send > > And all of the others are optional but still useful: > > Template-GD > Email-MIME-Attachment-Stripper > Email-Reply > > In particular, Template-GD really should be in FE--it was > originally part of Template-Toolkit and was moved out in version 2.15. > > I figured I'd let you know sooner rather than later, when users > kept asking you for the packages, or when you had to build them anyway > to build a new Bugzilla package. :-) Welp, this request is finally done. All of the versions of Fedora currently supported (5, 6, and 7, when released) now have packaged versions of: perl-Email-Send perl-Email-Abstract perl-Return-Value perl-Email-MIME-Attachment-Stripper perl-Email-Reply perl-Email-MIME-Creator perl-Email-Simple-Creator perl-Email-Date perl-Mail-Box-Parser-C perl-Mail-Box perl-Mail-Transport-Dbx perl-Mail-IMAPClient perl-Object-Realize-Later perl-User-Identity perl-Geography-Countries perl-Template-GD All of these were needed to meet the missing bugzilla requirements that Max posted back in February. Thanks for the heads up, sorry it took so long to get this done. ~spot From bugzilla at redhat.com Mon May 7 00:10:05 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 20:10:05 -0400 Subject: [Bug 232481] EPEL branches: a couple of perl packages from fedora.us In-Reply-To: Message-ID: <200705070010.l470A5Au018167@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 Mon May 7 03:48:35 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 6 May 2007 23:48:35 -0400 Subject: [Bug 239118] perl-YAML-Syck fails to build due to missing perl-Devel-Leak in ppc64 In-Reply-To: Message-ID: <200705070348.l473mZdo023019@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-YAML-Syck fails to build due to missing perl-Devel-Leak in ppc64 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239118 notting at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |MODIFIED ------- Additional Comments From notting at redhat.com 2007-05-06 23:48 EST ------- Should be available now. -- 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 May 7 16:53:19 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 May 2007 12:53:19 -0400 Subject: [Bug 239333] New: Branch perl-Net-Server for EPEL 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=239333 Summary: Branch perl-Net-Server for EPEL Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-Net-Server AssignedTo: nicolas.mailhot at laposte.net ReportedBy: kevin at tummy.com QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com perl-Net-Server was imported long ago from fedora.us, so there is no review ticket. I am thus filing this to request a EPEL branch for it. The current Fedora maintainer has no interest in maintaining for EPEL, so I will do so. Package Change Request ====================== Package Name: perl-Net-Server New Branches: EL-4 EL-5 Updated EPEL Owners: kevin at tummy.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 May 7 16:53:55 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 May 2007 12:53:55 -0400 Subject: [Bug 239333] Branch perl-Net-Server for EPEL In-Reply-To: Message-ID: <200705071653.l47Grt3a032373@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: Branch perl-Net-Server for EPEL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239333 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |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 Mon May 7 20:20:45 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 7 May 2007 16:20:45 -0400 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200705072020.l47KKjgR019732@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 ------- Additional Comments From rnorwood at redhat.com 2007-05-07 16:20 EST ------- Oh. I assumed f7 was going to include the newer version of rpm (your comment #10), but it looks like we're at 4.4.2. Anyway, built for f7, I'll send a request to rel-eng folks that it be included. -- 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 May 7 07:49:49 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 07 May 2007 09:49:49 +0200 Subject: Test::Pod::Coverage tests... In-Reply-To: <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> References: <7dd7ab490704271018t6a2ef883q88e6944a7e54c1c9@mail.gmail.com> <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> Message-ID: <1178524190.3504.10.camel@mccallum.corsepiu.local> On Fri, 2007-05-04 at 16:12 -0700, Chris Weyl wrote: > On 4/27/07, Chris Weyl wrote: > > My opinion is that we ought to not mandate the use of Pod coverage > > tests, simply because for our purposes it doesn't really matter what > > their result is. If they're present, we should conditionalize the > > tests (e.g. %_with_pod_tests magic or some such), but not insist on > > them by default. > > So, to follow up to myself here, given the lack of comments I'm > inclined to approve 237883 without insisting on Test::Pod::Coverage > due to T::P::C not testing the _functionality_ of the package. You don't want to know about the bugs and deficits your packages suffer from? But then let's be consequent and mandate disabling all testsuites, avoids a lot of fuzz and lets the distro appear "free of bugs". > One > last chance to scream :) YELL! Ralf From tibbs at math.uh.edu Mon May 7 23:04:04 2007 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: 07 May 2007 18:04:04 -0500 Subject: Test::Pod::Coverage tests... In-Reply-To: <1178524190.3504.10.camel@mccallum.corsepiu.local> References: <7dd7ab490704271018t6a2ef883q88e6944a7e54c1c9@mail.gmail.com> <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> <1178524190.3504.10.camel@mccallum.corsepiu.local> Message-ID: >>>>> "RC" == Ralf Corsepius writes: RC> You don't want to know about the bugs and deficits your packages RC> suffer from? Well, to play devil's advocate, if we're to consider lack of documentation coverage a bug and block inclusion of packages due to those bugs, then we shouldn't even have a kernel. Of course we should run test suites, and we should of course block packages when those test suites fail but are expected to pass. But blocking due to lack of documentation coverage is pushing things a bit beyond the bounds of reason. - J< From rc040203 at freenet.de Tue May 8 06:34:52 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 08 May 2007 08:34:52 +0200 Subject: Test::Pod::Coverage tests... In-Reply-To: References: <7dd7ab490704271018t6a2ef883q88e6944a7e54c1c9@mail.gmail.com> <7dd7ab490705041612m17080eb8od8fdabaf818b6e8f@mail.gmail.com> <1178524190.3504.10.camel@mccallum.corsepiu.local> Message-ID: <1178606092.3504.79.camel@mccallum.corsepiu.local> On Mon, 2007-05-07 at 18:04 -0500, Jason L Tibbitts III wrote: > >>>>> "RC" == Ralf Corsepius writes: > > RC> You don't want to know about the bugs and deficits your packages > RC> suffer from? > > Well, to play devil's advocate, if we're to consider lack of > documentation coverage a bug and block inclusion of packages due to > those bugs, then we shouldn't even have a kernel. This is not about "lack of docs", but about packages failing their their own testsuites, because packages ship with broken testsuites. A "reasonable" upstream being conscious about their weaknesses/deficits ("known bugs") would change their testsuite to "degrade gracefully" (e.g. to complain only). > Of course we should run test suites, and we should of course block > packages when those test suites fail but are expected to pass. But > blocking due to lack of documentation coverage is pushing things a bit > beyond the bounds of reason. Well, I guess you are aware that a perl-module without sufficiently complete docs (pods) is almost useless. Ralf From bugzilla at redhat.com Tue May 8 14:22:55 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 May 2007 10:22:55 -0400 Subject: [Bug 184530] Review Request: perl-RPM2 In-Reply-To: Message-ID: <200705081422.l48EMtk2022186@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 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |CURRENTRELEASE Fixed In Version| |F7 ------- Additional Comments From rnorwood at redhat.com 2007-05-08 10:22 EST ------- """ Package: perl-RPM2 NVR: perl-RPM2-0.67-2.fc7 User: jkeating Status: complete Tag Operation: tagged Into Tag: f7-final perl-RPM2-0.67-2.fc7 successfully tagged into f7-final by jkeating """ Ok, Jose, *now* can I close the 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 Tue May 8 14:50:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 May 2007 10:50:52 -0400 Subject: [Bug 239118] perl-YAML-Syck fails to build due to missing perl-Devel-Leak in ppc64 In-Reply-To: Message-ID: <200705081450.l48EoqhP024744@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-YAML-Syck fails to build due to missing perl-Devel-Leak in ppc64 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239118 cweyl at alumni.drew.edu changed: What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |CLOSED Resolution| |RAWHIDE ------- Additional Comments From cweyl at alumni.drew.edu 2007-05-08 10:50 EST ------- Yep, all set! 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 Tue May 8 18:12:51 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 8 May 2007 14:12:51 -0400 Subject: [Bug 235835] can you build for EL5? In-Reply-To: Message-ID: <200705081812.l48ICpRX011400@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: can you build for EL5? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=235835 ------- Additional Comments From bpeck at redhat.com 2007-05-08 14:12 EST ------- ping? -- 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 jpo at di.uminho.pt Wed May 9 20:10:03 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Wed, 09 May 2007 21:10:03 +0100 Subject: Perl splitting Message-ID: <46422A9B.3090205@di.uminho.pt> Hi, As I have been rather busy in the past months I haven't had the time to follow the mailing lists and only this weekend did I realize that the disruptive [1] change of splitting perl had been pushed through. Questions: 1) What exactly do we gain with such splitting? 2) How did such a disruptive change got through Red-Eng as I haven't seen it announced as a milestone for F7 ? http://fedoraproject.org/wiki/CategoryFedora7Features 3) Again how does this only gets committed this last weekend (after the 4th test release)? 4) How does a company plans to release a product with several hundred packages broken (SRPMs that users won't be able to rebuild)? Thanks in advance for your time, jpo (a very concerned user/packager that sees lot of his scripts broken because of missing perl core modules and doesn't want to review all his specfiles in order to add perl core modules to the build requirements list) [1] - affects more than 650 packages -- Jos? Pedro Oliveira * mailto:jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ * From bugzilla at redhat.com Wed May 9 20:10:57 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 9 May 2007 16:10:57 -0400 Subject: [Bug 239333] Branch perl-Net-Server for EPEL In-Reply-To: Message-ID: <200705092010.l49KAvS1002830@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: Branch perl-Net-Server for EPEL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239333 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 rc040203 at freenet.de Thu May 10 04:45:34 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 10 May 2007 06:45:34 +0200 Subject: Perl splitting In-Reply-To: <46422A9B.3090205@di.uminho.pt> References: <46422A9B.3090205@di.uminho.pt> Message-ID: <1178772335.7713.11.camel@mccallum.corsepiu.local> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: > Hi, > > As I have been rather busy in the past months I haven't had the time > to follow the mailing lists and only this weekend did I realize that > the disruptive [1] change of splitting perl had been pushed through. > > Questions: Disclaimer: All answer are my personal view and opinion. > 1) What exactly do we gain with such splitting? - Smaller install size - Smaller buildsys size - Introduces real perl-module build-deps instead of a dependency on a "lumped-together" meta-rpm (=> improved long term stability of perl module packages) - The option to upgrade/replace "core perl modules". > 2) How did such a disruptive change got through Red-Eng as I haven't > seen it announced as a milestone for F7 ? > http://fedoraproject.org/wiki/CategoryFedora7Features rel-eng would have to answer. > 3) Again how does this only gets committed this last weekend > (after the 4th test release)? The split had been pending and discussed here for many weeks, but progress on the perl package had been a snail. Some details had been controversial, some details were broken, but 90% of the delays had been caused by collaboration not working. IMO, the currently split is only "half of the story" and far from being complete. > 4) How does a company plans to release a product with several > hundred packages broken (SRPMs that users won't be able to rebuild)? Which harm does this to the Fedora run-time? It's a "grandfathering" approach and it's actually not different from not performing an ordered mass rebuilt. > Thanks in advance for your time, > jpo > (a very concerned user/packager that sees lot of his scripts broken > because of missing perl core modules and doesn't want to review all his > specfiles in order to add perl core modules to the build requirements list) It's much less effort than you expect. 1. In almost all cases you will see hard rebuild-breakdowns with obvious "easy-fixes". In 90% of all cases all that would be required is to add "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) "BuildRequires: perl(Test::More)". 2. Such issues could easily be approached by a perl-SWAT team, but ... 3. It's a grandfathering approach. There is no need to rebuild everything. Ralf From rnorwood at redhat.com Thu May 10 16:04:51 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 10 May 2007 12:04:51 -0400 Subject: Perl splitting In-Reply-To: <1178772335.7713.11.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Thu, 10 May 2007 06:45:34 +0200") References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: >> Hi, >> >> As I have been rather busy in the past months I haven't had the time >> to follow the mailing lists and only this weekend did I realize that >> the disruptive [1] change of splitting perl had been pushed through. >> >> Questions: > Disclaimer: All answer are my personal view and opinion. > >> 1) What exactly do we gain with such splitting? > - Smaller install size > - Smaller buildsys size > - Introduces real perl-module build-deps instead of a dependency on a > "lumped-together" meta-rpm (=> improved long term stability of perl > module packages) > - The option to upgrade/replace "core perl modules". That pretty much covers it as far as I'm concerned. >> 2) How did such a disruptive change got through Red-Eng as I haven't >> seen it announced as a milestone for F7 ? >> http://fedoraproject.org/wiki/CategoryFedora7Features > rel-eng would have to answer. > >> 3) Again how does this only gets committed this last weekend >> (after the 4th test release)? > The split had been pending and discussed here for many weeks, but > progress on the perl package had been a snail. Some details had been > controversial, some details were broken, but 90% of the delays had been > caused by collaboration not working. A large part of the problem was that I was distracted with other Red Hat projects. Also, I'm still very new at the whole packaging business, and had to rely on Spot and others for the bulk of the actual work here. So, I take full responsibility/blame for both the changes taking so long, and for them being pushed through so late. My feeling was that it is better to move ahead with this, and suffer angry module owners, than to wait for yet another release for these improvements. > IMO, the currently split is only "half of the story" and far from being > complete. #1 on my list is to get rid of the 'perlmodcompat' mess early in the F8 cycle. If anyone knows of a situation where the modcompat stuff actually useful at this point, let me know. >> 4) How does a company plans to release a product with several >> hundred packages broken (SRPMs that users won't be able to rebuild)? > Which harm does this to the Fedora run-time? It's a "grandfathering" > approach and it's actually not different from not performing an ordered > mass rebuilt. SRPMs can be rebuilt - the BuildRequires will be wrong, and the module authors will understandably be very annoyed with me, and will probably yell at me. I can take it. > 1. In almost all cases you will see hard rebuild-breakdowns with obvious > "easy-fixes". In 90% of all cases all that would be required is to add > "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) > "BuildRequires: perl(Test::More)". > > 2. Such issues could easily be approached by a perl-SWAT team, but ... > > 3. It's a grandfathering approach. There is no need to rebuild > everything. ^ What he said. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From jpo at di.uminho.pt Sun May 13 17:40:17 2007 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Sun, 13 May 2007 18:40:17 +0100 Subject: Perl splitting In-Reply-To: References: <46422A9B.3090205@di.uminho.pt><1178772335.7713.11.camel@mccallu m.corsepiu.local> Message-ID: <46474D81.7080807@di.uminho.pt> Robin Norwood wrote: > Ralf Corsepius writes: > >> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: >>> Hi, >>> >>> As I have been rather busy in the past months I haven't had the time >>> to follow the mailing lists and only this weekend did I realize that >>> the disruptive [1] change of splitting perl had been pushed through. >>> >>> Questions: >> Disclaimer: All answer are my personal view and opinion. >> >>> 1) What exactly do we gain with such splitting? >> - Smaller install size Does this justify breaking what people come to expect in a perl runtime environment, i.e., that every perl core module is available? Isn't people loosing perspective by just looking at the packaging side of the question? This kind of change breaks end user code as the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed by default. >> - Smaller buildsys size Hardly worth the effort as almost every perl package will require ExtUtils::MakeMaker and one or more of the Test modules. >> - Introduces real perl-module build-deps instead of a dependency on a >> "lumped-together" meta-rpm (=> improved long term stability of perl >> module packages) It will introduce maintenance problems in the long run as you continue to split core perl modules and also fail to follow the way upstream ships dual life perl modules (just look as ExtUtils::MakeMaker has been splitted in severeal sub-modules in recent years. Also perl 5.10 is around the corner and will "offer" you plenty more modules to be splitted (just think Module::Build and all its dependencies). >> - The option to upgrade/replace "core perl modules". Can you give a concrete example of this? > That pretty much covers it as far as I'm concerned. As it stands this change completely broke what I come to expect in every platform I have to work with perl (installing and support several perl apps). As this change is to disruptive to me I will most likely start phasing out Fedora as my main linux platform (and losing interest in continuing supporting the Perl packages I maintain). This change also pollutes the perl specfiles with additional BR (perl core modules) and goes against what we have been doing for the last 3+ years (at least since Fedora.US). >>> 2) How did such a disruptive change got through Red-Eng as I haven't >>> seen it announced as a milestone for F7 ? >>> http://fedoraproject.org/wiki/CategoryFedora7Features >> rel-eng would have to answer. >> >>> 3) Again how does this only gets committed this last weekend >>> (after the 4th test release)? >> The split had been pending and discussed here for many weeks, but >> progress on the perl package had been a snail. Some details had been >> controversial, some details were broken, but 90% of the delays had been >> caused by collaboration not working. > > A large part of the problem was that I was distracted with other Red Hat > projects. Also, I'm still very new at the whole packaging business, and > had to rely on Spot and others for the bulk of the actual work here. > So, I take full responsibility/blame for both the changes taking so > long, and for them being pushed through so late. My feeling was that it > is better to move ahead with this, and suffer angry module owners, than > to wait for yet another release for these improvements. > >> IMO, the currently split is only "half of the story" and far from being >> complete. > > #1 on my list is to get rid of the 'perlmodcompat' mess early in the F8 > cycle. If anyone knows of a situation where the modcompat stuff > actually useful at this point, let me know. > >>> 4) How does a company plans to release a product with several >>> hundred packages broken (SRPMs that users won't be able to rebuild)? >> Which harm does this to the Fedora run-time? It's a "grandfathering" >> approach and it's actually not different from not performing an ordered >> mass rebuilt. > > SRPMs can be rebuilt - the BuildRequires will be wrong, and the module > authors will understandably be very annoyed with me, and will probably > yell at me. I can take it. > >> 1. In almost all cases you will see hard rebuild-breakdowns with obvious >> "easy-fixes". In 90% of all cases all that would be required is to add >> "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) >> "BuildRequires: perl(Test::More)". I believe you are being a little optimistic here. While adding ExtUtils::MakeMaker is trivial, adding Test::More, Test::Simple, and Test::Builder* is not. >> 2. Such issues could easily be approached by a perl-SWAT team, but ... >> >> 3. It's a grandfathering approach. There is no need to rebuild >> everything. > > ^ What he said. > > -RN > jpo -- Jos? Pedro Oliveira * mailto:jpo at di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ * From cweyl at alumni.drew.edu Sun May 13 19:22:58 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Sun, 13 May 2007 12:22:58 -0700 Subject: Perl splitting In-Reply-To: <46474D81.7080807@di.uminho.pt> References: <46422A9B.3090205@di.uminho.pt> <46474D81.7080807@di.uminho.pt> Message-ID: <7dd7ab490705131222x69a504b5t71e2a8ca21ef12d7@mail.gmail.com> On 5/13/07, Jose Pedro Oliveira wrote: > Robin Norwood wrote: > > Ralf Corsepius writes: > > > >> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: > >>> Hi, > >>> > >>> As I have been rather busy in the past months I haven't had the time > >>> to follow the mailing lists and only this weekend did I realize that > >>> the disruptive [1] change of splitting perl had been pushed through. > >>> > >>> Questions: > >> Disclaimer: All answer are my personal view and opinion. > >> > >>> 1) What exactly do we gain with such splitting? > >> - Smaller install size > > Does this justify breaking what people come to expect in a > perl runtime environment, i.e., that every perl core module is > available? > > Isn't people loosing perspective by just looking at the packaging > side of the question? This kind of change breaks end user code as > the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed > by default. I raised this issue (and a number of the others you bring up) a while back; hopefully you'll get more traction with this than I did :( I'm not entirely sure why we're so focused on substituting our judgement for the perl team's as to what constitutes a core module, aside from some perverse fixation on breaking things and making life more difficult for everyone that touches anything perl in Fedora. --especially this late in the F7 release cycle! I mean, really, what _actual_ problem are we trying to solve with this split? What are we trying to fix here? > >> - Smaller buildsys size > > Hardly worth the effort as almost every perl package will require > ExtUtils::MakeMaker and one or more of the Test modules. And the splitted modules are hardly huge by any measure. I doubt it's unreasonable to claim there's more overhead in the additional rpm transactions/depsolving needed to handle installing the additional packages needed to supply these core modules. > >> - Introduces real perl-module build-deps instead of a dependency on a > >> "lumped-together" meta-rpm (=> improved long term stability of perl > >> module packages) I don't think it's fair to call perl a "meta-rpm", for a variety of obvious reasons. And even if the core perl tarball is a "meta-tarball", then at least its metaness is owned by a core perl team tasked with its maintenance. [...snip...] > This change also pollutes the perl specfiles with additional BR > (perl core modules) and goes against what we have been doing for > the last 3+ years (at least since Fedora.US). This has been an issue in reviews lately. People are packaging perl modules, and then being told "go add BR's on these core modules, but not those". It's confusing -- personally I feel like this split has taken a relatively well understood, straightforward process and made it fairly muddy -- shades of the recent review process changes. I asked it above, but it's worth reiterating: what _actual_problem_ are we fixing with this split? Is it worth it? -Chris -- Chris Weyl Ex astris, scientia From rc040203 at freenet.de Mon May 14 05:35:16 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 07:35:16 +0200 Subject: Perl splitting In-Reply-To: <46474D81.7080807@di.uminho.pt> References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> Message-ID: <1179120916.4735.274.camel@mccallum.corsepiu.local> On Sun, 2007-05-13 at 18:40 +0100, Jose Pedro Oliveira wrote: > Robin Norwood wrote: > > Ralf Corsepius writes: > > > >> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: > >>> Hi, > >>> > >>> As I have been rather busy in the past months I haven't had the time > >>> to follow the mailing lists and only this weekend did I realize that > >>> the disruptive [1] change of splitting perl had been pushed through. > >>> > >>> Questions: > >> Disclaimer: All answer are my personal view and opinion. > >> > >>> 1) What exactly do we gain with such splitting? > >> - Smaller install size > > Does this justify breaking what people come to expect in a > perl runtime environment, i.e., that every perl core module is > available? Yes. Sometimes it's time to break with old habits. > Isn't people loosing perspective by just looking at the packaging > side of the question? This kind of change breaks end user code as > the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed > by default. Where is the problem? perl had been sloppily packaged in former Fedora releases, now things are being cleaned up. > >> - Smaller buildsys size > > Hardly worth the effort as almost every perl package will require > ExtUtils::MakeMaker and one or more of the Test modules. Yes, but ... how many _users_ do really need ExtUtils::MakeMaker or Test:: modules? Perl devs will, normal users won't except when other package will pull them in. > >> - Introduces real perl-module build-deps instead of a dependency on a > >> "lumped-together" meta-rpm (=> improved long term stability of perl > >> module packages) > > It will introduce maintenance problems in the long run as you > continue to split core perl modules and also fail to follow the > way upstream ships dual life perl modules (just look as > ExtUtils::MakeMaker has been splitted in severeal sub-modules in > recent years. I don't see this as a problem. The rpms a perl module might be located in might change, but this should not affect a perl's module's dep on other modules. If they do, then perl has broken compatibility and we would be facing similar issues elsewhere. > Also perl 5.10 is around the corner and will "offer" you plenty > more modules to be splitted (just think Module::Build and all its > dependencies). Yes. Module::Build and friends are on my radar. They are amongst the reasons for why I said "this split is far from being complete". > >> - The option to upgrade/replace "core perl modules". > > Can you give a concrete example of this? Check this list's archive. There repeatedly have been such requests. Before the split, it was technically impossible to replace core perl modules, now we at least have the option to do so for those modules which have been split out. > >>> 4) How does a company plans to release a product with several > >>> hundred packages broken (SRPMs that users won't be able to rebuild)? > >> Which harm does this to the Fedora run-time? It's a "grandfathering" > >> approach and it's actually not different from not performing an ordered > >> mass rebuilt. > > > > SRPMs can be rebuilt - That's an urban legend. All rpms in Fedora have been built against a set of packages that had been valid (and were reported to work) at one point in time. Even the mass-rebuilds in previous releases didn't actually change much about this, because they were _unsorted_ rebuilds. > the BuildRequires will be wrong, and the module > > authors will understandably be very annoyed with me, and will probably > > yell at me. I have no idea what you are referring to. In case a user complains about an srpm you maintain not being rebuildable, you (the rpm-maintainer) can choose to fix it (essentially what "grandfathering" means - Fix upon request or need) or ignore this complaint. In case an rpm's maintainer complains when he rebuilds a package he had not touched for ages. Shall he update his spec, like he would have been forced to do during a mass rebuild. In case a perl-module author complains, ... I don't see how this is of any importance here. > >> 1. In almost all cases you will see hard rebuild-breakdowns with obvious > >> "easy-fixes". In 90% of all cases all that would be required is to add > >> "BuildRequires: perl(ExtUtils::MakeMaker)" and (less frequent) > >> "BuildRequires: perl(Test::More)". > > I believe you are being a little optimistic here. While adding > ExtUtils::MakeMaker is trivial, adding Test::More, Test::Simple, > and Test::Builder* is not. Then let me put it this way: I haven't encountered any case where fixing had not been possible (and actually can imagine any situation where this would not be possible). In 90% of those cases I've adjusted it, it was adding "BuildRequires: perl(ExtUtils::MakeMaker)" (because most perl dists use EU:MM) and adding "perl(Test::More)" (for those case shipping testcases, almost all of EU::MM based dists). > >> 2. Such issues could easily be approached by a perl-SWAT team, but ... I find it remarkable that none of you commented on this. Ralf From rc040203 at freenet.de Mon May 14 05:51:23 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 14 May 2007 07:51:23 +0200 Subject: Perl splitting In-Reply-To: <7dd7ab490705131222x69a504b5t71e2a8ca21ef12d7@mail.gmail.com> References: <46422A9B.3090205@di.uminho.pt> <46474D81.7080807@di.uminho.pt> <7dd7ab490705131222x69a504b5t71e2a8ca21ef12d7@mail.gmail.com> Message-ID: <1179121884.4735.291.camel@mccallum.corsepiu.local> On Sun, 2007-05-13 at 12:22 -0700, Chris Weyl wrote: > On 5/13/07, Jose Pedro Oliveira wrote: > > Robin Norwood wrote: > > > Ralf Corsepius writes: > > > > > >> On Wed, 2007-05-09 at 21:10 +0100, Jose Pedro Oliveira wrote: > > >>> Hi, > > >>> > > >>> As I have been rather busy in the past months I haven't had the time > > >>> to follow the mailing lists and only this weekend did I realize that > > >>> the disruptive [1] change of splitting perl had been pushed through. > > >>> > > >>> Questions: > > >> Disclaimer: All answer are my personal view and opinion. > > >> > > >>> 1) What exactly do we gain with such splitting? > > >> - Smaller install size > > > > Does this justify breaking what people come to expect in a > > perl runtime environment, i.e., that every perl core module is > > available? > > > > Isn't people loosing perspective by just looking at the packaging > > side of the question? This kind of change breaks end user code as > > the Test and CPAN/ExtUtils::MakeMaker modules are no longer installed > > by default. > > I raised this issue (and a number of the others you bring up) a while > back; hopefully you'll get more traction with this than I did :( > > I'm not entirely sure why we're so focused on substituting our > judgement for the perl team's as to what constitutes a core module, > aside from some perverse fixation on breaking things and making life > more difficult for everyone that touches anything perl in Fedora. > --especially this late in the F7 release cycle! > > I mean, really, what _actual_ problem are we trying to solve with this > split? What are we trying to fix here? > > > >> - Smaller buildsys size > > > > Hardly worth the effort as almost every perl package will require > > ExtUtils::MakeMaker and one or more of the Test modules. > > And the splitted modules are hardly huge by any measure. The vast majority of perl modules are small, so this is to be expected. The real point of package splits is cutting out functionality and making implicit package deps visible. IMO, e.g. having cut out "cpan" alone is worth it. It implies user wanting to corrupt their rpm-based perl-installation will manually have to install it. Splitting out EU::MM and Test::* makes (perl-module) deps visible Fedora's packaging policy so far has ignored - I don't see this a disadvantage. > > >> - Introduces real perl-module build-deps instead of a dependency on a > > >> "lumped-together" meta-rpm (=> improved long term stability of perl > > >> module packages) > > I don't think it's fair to call perl a "meta-rpm", for a variety of > obvious reasons. And even if the core perl tarball is a > "meta-tarball", then at least its metaness is owned by a core perl > team tasked with its maintenance. Of cause I do not agree with you. To me the perl rpm has a "take everything/meta-rpm", lumping together many unrelated subpackages. I.e. a defect in packaging policy. I take the fact "upstream lumps them together", * as a symptom of the clash between perl-upstream's and rpm's working principles (cpan vs. rpm). * as an indication of a clash between Fedora's principle to separate "run-time" from "devel" and perl upstream's principles. > > This change also pollutes the perl specfiles with additional BR > > (perl core modules) and goes against what we have been doing for > > the last 3+ years (at least since Fedora.US). > > This has been an issue in reviews lately. People are packaging perl > modules, and then being told "go add BR's on these core modules, but > not those". It's confusing -- personally I feel like this split has > taken a relatively well understood, straightforward process and made > it fairly muddy -- shades of the recent review process changes. > > I asked it above, but it's worth reiterating: what _actual_problem_ > are we fixing with this split? Answered before. > Is it worth it? Yes. It installing unused packages. Ralf From rnorwood at redhat.com Mon May 14 15:19:08 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 14 May 2007 11:19:08 -0400 Subject: Perl splitting In-Reply-To: <1179120916.4735.274.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Mon, 14 May 2007 07:35:16 +0200") References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: [...] >> the BuildRequires will be wrong, and the module >> > authors will understandably be very annoyed with me, and will probably >> > yell at me. > I have no idea what you are referring to. I think the threading got broken here. This was me speaking, and I meant to say 'package owners' instead of 'module authors'. > In case a user complains about an srpm you maintain not being > rebuildable, you (the rpm-maintainer) can choose to fix it (essentially > what "grandfathering" means - Fix upon request or need) or ignore this > complaint. > > In case an rpm's maintainer complains when he rebuilds a package he had > not touched for ages. Shall he update his spec, like he would have been > forced to do during a mass rebuild. And he'll yell at me, probably. I'm ok with this. >> >> 2. Such issues could easily be approached by a perl-SWAT team, but ... > I find it remarkable that none of you commented on this. Are you volunteering to start one? I'll be happy to help as much as I can, time permitting. :-) -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 May 14 22:51:22 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 00:51:22 +0200 Subject: Perl splitting In-Reply-To: References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> Message-ID: <1179183082.4735.383.camel@mccallum.corsepiu.local> On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote: > Ralf Corsepius writes: > > >> >> 2. Such issues could easily be approached by a perl-SWAT team, but ... > > I find it remarkable that none of you commented on this. > > Are you volunteering to start one? I'll be happy to help as much as I > can, time permitting. :-) Again, a comment I can't deny to find remarkable. I've been agitating to see "collaborative maintainership" to replace this unfortunate "one-package/one-owner" maintainership policy in Fedora ever since Fedora exists. So far, there have always been circles in Fedora which strangled any such attempt. Ralf From shiva at sewingwitch.com Tue May 15 00:06:47 2007 From: shiva at sewingwitch.com (Kenneth Porter) Date: Mon, 14 May 2007 17:06:47 -0700 Subject: Perl splitting In-Reply-To: <1179120916.4735.274.camel@mccallum.corsepiu.local> References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> Message-ID: <83EC471D07F5CF385D285B42@[10.169.6.226]> On Monday, May 14, 2007 7:35 AM +0200 Ralf Corsepius wrote: > Yes, but ... how many _users_ do really need ExtUtils::MakeMaker or > Test:: modules? Perl devs will, normal users won't except when other > package will pull them in. > Before the split, it was technically impossible to replace core perl > modules, now we at least have the option to do so for those modules > which have been split out. In fact, EU:MM is exactly the module I needed to manually upgrade in the past, and had to install a local (unpackaged) version in my build environment to do so. I see this as a boon to dealing with broken outdated core packages that can now be updated in isolation without the extreme of updating the entire core. This doesn't affect Fedora so much, with its rapid pace of development, but other, more conservative distros (eg. RHEL and CentOS) inherit Fedora packages and will benefit from this compartmentalization of change. From rnorwood at redhat.com Tue May 15 14:48:39 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 15 May 2007 10:48:39 -0400 Subject: Perl splitting In-Reply-To: <1179183082.4735.383.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 15 May 2007 00:51:22 +0200") References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <1179183082.4735.383.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote: >> Ralf Corsepius writes: > >> >> >> >> 2. Such issues could easily be approached by a perl-SWAT team, but ... >> > I find it remarkable that none of you commented on this. >> >> Are you volunteering to start one? I'll be happy to help as much as I >> can, time permitting. :-) > Again, a comment I can't deny to find remarkable. > > I've been agitating to see "collaborative maintainership" to replace > this unfortunate "one-package/one-owner" maintainership policy in Fedora > ever since Fedora exists. > > So far, there have always been circles in Fedora which strangled any > such attempt. Well, what does collaborative maintainership mean to you, exactly? As you probably know, the vast majority of the recent changes to perl's spec file were contributed by spot and yourself - that's pretty collaborative. If you want commit access, one of the benefits of the merge is that you (or anyone else with a track record) could become a co-maintainer of any package in Fedora, not just the 'extras'. We wouldn't want just anyone to have commit access, obviously. Personally, I wouldn't want to get rid of the maintainer idea entirely, either - I think the personal responsibility and accountability implied by the maintainer role count for a lot. -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 May 15 15:33:54 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 15 May 2007 17:33:54 +0200 Subject: Perl splitting In-Reply-To: References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <1179183082.4735.383.camel@mccallum.corsepiu.local> Message-ID: <1179243234.4735.542.camel@mccallum.corsepiu.local> On Tue, 2007-05-15 at 10:48 -0400, Robin Norwood wrote: > Ralf Corsepius writes: > > > On Mon, 2007-05-14 at 11:19 -0400, Robin Norwood wrote: > >> Ralf Corsepius writes: > > > >> > >> >> >> 2. Such issues could easily be approached by a perl-SWAT team, but ... > >> > I find it remarkable that none of you commented on this. > >> > >> Are you volunteering to start one? I'll be happy to help as much as I > >> can, time permitting. :-) > > Again, a comment I can't deny to find remarkable. > > > > I've been agitating to see "collaborative maintainership" to replace > > this unfortunate "one-package/one-owner" maintainership policy in Fedora > > ever since Fedora exists. > > > > So far, there have always been circles in Fedora which strangled any > > such attempt. > > Well, what does collaborative maintainership mean to you, exactly? A team of equal (senior-, overseer-) maintainers simultaneously working collaboratively on something. Not "a subordinate coding-monkey submits" something to a "devine maintainer", who applies a submitted change with several weeks of delay inbetween. Of cause this requires some amount of trust and some amount of "self-distrust" and "self-reality check" ("I would like to ... but am not sure about it/this is not my domain ..."). Cf. how e.g. GCC works. Many people have privileges to access all files of the GCC source tree, but are supposed only to touch certain files or certain areas. Wrt. perl rpms, the same principle could mean a "perl-packaging SWAT team" updating BR's of perl-module packages to reflect changes having been incorporated into the main perl. Wrt. to the main perl package, this could have meant Spot, Ville or me to apply our patches ourselves and us having rebuilt the packages after you would have OK'ed the patches. It would have lifted some burden off your shoulders without many side-effects. > As > you probably know, the vast majority of the recent changes to perl's > spec file were contributed by spot and yourself - that's pretty > collaborative. May-be in comparison to how RH had processed RFEs so far - I can't judge. >From my POV, things actually did not proceed substantially different as they would have done before the "Core/Extras" merger. I could have submitted patches as an RFE in bugzilla and wait for somebody @RH to react. > If you want commit access, one of the benefits of the > merge is that you (or anyone else with a track record) could become a > co-maintainer of any package in Fedora, not just the 'extras'. We > wouldn't want just anyone to have commit access, obviously. Personally, > I wouldn't want to get rid of the maintainer idea entirely, either - I > think the personal responsibility and accountability implied by the > maintainer role count for a lot. It might surprise you but I don't disagree on this. There always needs to be some "authority with the final say", be it an individual or a committee or simply "majority". In GCC it's coordinated by applying different "patch policies" on different development branches and by "approving patches/patch reviews". Wrt. FC this could mean: "Write after approval to any 'senior Fedora developer' on 'rawhide'", "Maintainer write-only on releases". Ralf From rnorwood at redhat.com Tue May 15 17:45:28 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 15 May 2007 13:45:28 -0400 Subject: Perl splitting In-Reply-To: <1179243234.4735.542.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Tue, 15 May 2007 17:33:54 +0200") References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <1179183082.4735.383.camel@mccallum.corsepiu.local> <1179243234.4735.542.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Tue, 2007-05-15 at 10:48 -0400, Robin Norwood wrote: >> Well, what does collaborative maintainership mean to you, exactly? > A team of equal (senior-, overseer-) maintainers simultaneously working > collaboratively on something. > > Not "a subordinate coding-monkey submits" something to a "devine > maintainer", who applies a submitted change with several weeks of delay > inbetween. > > Of cause this requires some amount of trust and some amount of > "self-distrust" and "self-reality check" ("I would like to ... but am > not sure about it/this is not my domain ..."). > > Cf. how e.g. GCC works. Many people have privileges to access all files > of the GCC source tree, but are supposed only to touch certain files or > certain areas. > > Wrt. perl rpms, the same principle could mean a "perl-packaging SWAT > team" updating BR's of perl-module packages to reflect changes having > been incorporated into the main perl. I'm not entirely sure how this would work in practice - the obvious way is to add a group of people as co-maintainers to all packages in the perl-* namespace. But I think we would want to ask existing maintainers before doing this to their packages, and I'm not sure how new perl-* packages would work, except by someone manually taking care of it (maybe if the package review process for new perl packages included this step. Would this be good enough? Do you have a better way? > Wrt. to the main perl package, this could have meant Spot, Ville or me > to apply our patches ourselves and us having rebuilt the packages after > you would have OK'ed the patches. It would have lifted some burden off > your shoulders without many side-effects. I'd be totally ok with this. Can I take this thread as a request by you to be added to the list of maintainers for perl? Spot had mentioned being added himself recently. Ville? Anyone else? >> If you want commit access, one of the benefits of the >> merge is that you (or anyone else with a track record) could become a >> co-maintainer of any package in Fedora, not just the 'extras'. We >> wouldn't want just anyone to have commit access, obviously. Personally, >> I wouldn't want to get rid of the maintainer idea entirely, either - I >> think the personal responsibility and accountability implied by the >> maintainer role count for a lot. > It might surprise you but I don't disagree on this. There always needs > to be some "authority with the final say", be it an individual or a > committee or simply "majority". In GCC it's coordinated by applying > different "patch policies" on different development branches and by > "approving patches/patch reviews". > > Wrt. FC this could mean: "Write after approval to any 'senior Fedora > developer' on 'rawhide'", "Maintainer write-only on releases". I think the release engineering and infrastructure teams are looking at these sorts of rules, but the tools don't exist yet, AFAIK. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From bugzilla at redhat.com Tue May 15 18:09:08 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 May 2007 14:09:08 -0400 Subject: [Bug 240192] New: Add co-maintainers to the perl RPM 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=240192 Summary: Add co-maintainers to the perl RPM Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: rnorwood at redhat.com QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Package Change Request ====================== Package Name: perl Updated Fedora Owners: rc040203 at freenet.de, tcallawa at redhat.com Updated Fedora CC: rc040203 at freenet.de, tcallawa 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 Tue May 15 18:09:33 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 May 2007 14:09:33 -0400 Subject: [Bug 240192] Add co-maintainers to the perl RPM In-Reply-To: Message-ID: <200705151809.l4FI9X3D031885@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: Add co-maintainers to the perl RPM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240192 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |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 Tue May 15 18:11:22 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 15 May 2007 14:11:22 -0400 Subject: [Bug 240192] Add co-maintainers to the perl RPM In-Reply-To: Message-ID: <200705151811.l4FIBMGg032088@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: Add co-maintainers to the perl RPM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240192 rnorwood 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 rnorwood at redhat.com Wed May 16 15:32:00 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Wed, 16 May 2007 11:32:00 -0400 Subject: More on perl for F7 Message-ID: Hi, We've been discussing the perl split and how to minimize disruption for users. Warren, spot, and I are seeing about getting the 'core' perl packages that have been split into separate RPMs added to the list of packages that get installed by default whenever perl is installed. This way, most users will still have CPAN + co, but we'll still have most of the advantages we wanted from splitting them out in the first place. This basically changes the 'build/devel' related perl modules from opt-in to opt-out for F7. What do you think? For reference, these are the packages in question: perl-devel perl-CPAN perl-ExtUtils-Embed perl-ExtUtils-MakeMaker perl-Test-Harness perl-Test-Simple -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 May 16 20:39:50 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 16 May 2007 16:39:50 -0400 Subject: [Bug 240192] Add co-maintainers to the perl RPM In-Reply-To: Message-ID: <200705162039.l4GKdoN4001635@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: Add co-maintainers to the perl RPM https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240192 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 rc040203 at freenet.de Thu May 17 03:24:12 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 05:24:12 +0200 Subject: More on perl for F7 In-Reply-To: References: Message-ID: <1179372253.4735.785.camel@mccallum.corsepiu.local> On Wed, 2007-05-16 at 11:32 -0400, Robin Norwood wrote: > Hi, > > We've been discussing the perl split and how to minimize disruption for > users. Warren, spot, and I are seeing about getting the 'core' perl > packages that have been split into separate RPMs added to the list of > packages that get installed by default whenever perl is installed. This > way, most users will still have CPAN + co, but we'll still have most of > the advantages we wanted from splitting them out in the first place. > > This basically changes the 'build/devel' related perl modules from > opt-in to opt-out for F7. > > What do you think? Wrong move. This renders perl-devel into a meta-package and voids/avoids forcing users to use full BuildRequires. I.e. this widely spoils and voids one fundamental aspect the split is aiming at. Ralf From bugzilla at redhat.com Thu May 17 09:55:18 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 17 May 2007 05:55:18 -0400 Subject: [Bug 240401] New: Typo in /etc/logrotate.d/sa-update 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=240401 Summary: Typo in /etc/logrotate.d/sa-update Product: Red Hat Enterprise Linux Version: 5 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: spamassassin AssignedTo: wtogami at redhat.com ReportedBy: jplans at redhat.com CC: GavinFlower at yahoo.com,_ at sucs.org,benny+bugzilla at amorsen. dk,bojan at rexursive.com,djuran at redhat.com,dmobrien_2001 at y ahoo.com,fedora-perl-devel-list at redhat.com,frank- buettner at gmx.net,hongjiu.lu at intel.com,ian at iay.org.uk,jm@ jmason.org,jm at mailsnare.net,mishu at piatafinanciara.ro,mus uruan at gmail.com,parkerm at pobox.com,reg+redhat at sidney.com, tom at compton.nu,tuju at iki.fi,wtogami at redhat.com +++ This bug was initially created as a clone of Bug #223753 +++ Description of problem: logrotate error message: error: sa-update:3 unknown option 'notifyempty' -- ignoring line Version-Release number of selected component (if applicable): spamassassin-3.1.7-4.fc6 Fix: Something like this: /var/log/sa-update.log { monthly - notifyempty + notifempty missingok } -- Additional comment from wtogami at redhat.com on 2007-01-23 10:49 EST -- *** Bug 223972 has been marked as a duplicate of this bug. *** -- Additional comment from _ at sucs.org on 2007-01-24 04:04 EST -- This applies to FC5 as well. -- Additional comment from joshua at iwsp.com on 2007-01-24 11:31 EST -- I get nightly email about this... apply that patch and push the fix!! -- Additional comment from wtogami at redhat.com on 2007-01-24 15:33 EST -- spamassassin-3.1.7-5.fcX will be pushed soon to solve this issue. -- Additional comment from wtogami at redhat.com on 2007-01-24 15:33 EST -- *** Bug 224179 has been marked as a duplicate of this bug. *** -- Additional comment from paul at city-fan.org on 2007-01-26 05:42 EST -- *** Bug 224547 has been marked as a duplicate of this bug. *** -- Additional comment from wtogami at redhat.com on 2007-01-28 00:05 EST -- This is now fixed in FC5 and FC6 updates. -- Additional comment from paul at city-fan.org on 2007-01-29 07:40 EST -- *** Bug 225144 has been marked as a duplicate of this bug. *** -- Additional comment from paul at city-fan.org on 2007-01-29 08:13 EST -- *** Bug 225039 has been marked as a duplicate of this bug. *** ------- Additional Comments From jplans at redhat.com 2007-05-17 05:55 EST ------- Created an attachment (id=154902) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=154902&action=view) sa-update.logrotate.patch -- 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 May 17 09:55:23 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 17 May 2007 05:55:23 -0400 Subject: [Bug 223753] Typo in /etc/logrotate.d/sa-update In-Reply-To: Message-ID: <200705170955.l4H9tNR0017918@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: Typo in /etc/logrotate.d/sa-update https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=223753 jplans at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |240401 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 May 17 09:56:06 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 17 May 2007 05:56:06 -0400 Subject: [Bug 240401] Typo in /etc/logrotate.d/sa-update In-Reply-To: Message-ID: <200705170956.l4H9u6Xl018101@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: Typo in /etc/logrotate.d/sa-update https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240401 jplans at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Flag| |rhel-5.2.0?, pm_ack?, | |devel_ack?, qa_ack? -- 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 May 17 10:26:47 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 17 May 2007 06:26:47 -0400 Subject: [Bug 240402] New: SpamAssassin sa-update gpg verification failure 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=240402 Summary: SpamAssassin sa-update gpg verification failure Product: Fedora Core Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: spamassassin AssignedTo: wtogami at redhat.com ReportedBy: amessina at messinet.com CC: fedora-perl-devel- list at redhat.com,felicity at kluge.net,jm at jmason.org,parkerm @pobox.com,reg+redhat at sidney.com,wtogami at redhat.com Description of problem: Each morning, I get a cron email stating that tht GPG verification of sa-update failed because it was signed with the wrong key. Even after following the instructions provided in the email, the error continues and the updates are not verified so they are not installed. Version-Release number of selected component (if applicable): spamassassin-3.1.8-2.fc6 How reproducible: With every cron run Steps to Reproduce: 1. Install spamassassin-3.1.8-2.fc6 2. Invoke the /etc/cron.d/sa-update script Actual results: An email is sent to with the following content: /etc/cron.daily/sa-update: error: GPG validation failed! The update downloaded successfully, but it was not signed with a trusted GPG key. Instead, it was signed with the following keys: 24F434CE Perhaps you need to import the channel's GPG key? For example: wget http://spamassassin.apache.org/updates/GPG.KEY sa-update --import GPG.KEY channel: GPG validation failed, channel failed Expected results: I expect that after following the instructions and installing the GPG key, that the next morning's updates would be processed without this same error. Additional info: I don't think it makes any difference here, but i do not run the spamassassin daemon because i run amavisd-new which calls spamassassin directly. -- 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 May 17 14:07:43 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 17 May 2007 10:07:43 -0400 Subject: [Bug 240401] Typo in /etc/logrotate.d/sa-update In-Reply-To: Message-ID: <200705171407.l4HE7h7w004185@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: Typo in /etc/logrotate.d/sa-update https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240401 wtogami at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG ------- Additional Comments From wtogami at redhat.com 2007-05-17 10:07 EST ------- This was fixed in RHEL5 day-0 security errata long ago. spamassassin-3.1.8-2.el5 -- 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 cweyl at alumni.drew.edu Thu May 17 15:17:48 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 17 May 2007 08:17:48 -0700 Subject: More on perl for F7 In-Reply-To: References: Message-ID: <7dd7ab490705170817h1c048409k60f774b126a3dd87@mail.gmail.com> On 5/16/07, Robin Norwood wrote: > Hi, > > We've been discussing the perl split and how to minimize disruption for > users. Warren, spot, and I are seeing about getting the 'core' perl > packages that have been split into separate RPMs added to the list of > packages that get installed by default whenever perl is installed. This > way, most users will still have CPAN + co, but we'll still have most of > the advantages we wanted from splitting them out in the first place. > > This basically changes the 'build/devel' related perl modules from > opt-in to opt-out for F7. > > What do you think? This could at least stabilize things for F7 -- everything is present the way it was in fc6, but ready for a more measured approach for F8. If we're going forward with the split I think this is a good way to do it. So how are we planning on doing this? A comps change or having core perl require it's subpackages? If it's just a comps change, how will this work with upgrades (via anaconda or, eg, a yum / apt upgrade)? -Chris -- Chris Weyl Ex astris, scientia From rc040203 at freenet.de Thu May 17 15:36:05 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 17:36:05 +0200 Subject: More on perl for F7 In-Reply-To: <7dd7ab490705170817h1c048409k60f774b126a3dd87@mail.gmail.com> References: <7dd7ab490705170817h1c048409k60f774b126a3dd87@mail.gmail.com> Message-ID: <1179416166.4735.833.camel@mccallum.corsepiu.local> On Thu, 2007-05-17 at 08:17 -0700, Chris Weyl wrote: > On 5/16/07, Robin Norwood wrote: > > Hi, > > > > We've been discussing the perl split and how to minimize disruption for > > users. Warren, spot, and I are seeing about getting the 'core' perl > > packages that have been split into separate RPMs added to the list of > > packages that get installed by default whenever perl is installed. This > > way, most users will still have CPAN + co, but we'll still have most of > > the advantages we wanted from splitting them out in the first place. > > > > This basically changes the 'build/devel' related perl modules from > > opt-in to opt-out for F7. > > > > What do you think? > > This could at least stabilize things for F7 -- everything is present > the way it was in fc6, Exactly: No progress. Development-wise a step backwards. Ralf From cweyl at alumni.drew.edu Thu May 17 17:09:08 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 17 May 2007 10:09:08 -0700 Subject: More on perl for F7 In-Reply-To: <1179416166.4735.833.camel@mccallum.corsepiu.local> References: <7dd7ab490705170817h1c048409k60f774b126a3dd87@mail.gmail.com> <1179416166.4735.833.camel@mccallum.corsepiu.local> Message-ID: <7dd7ab490705171009m56f46f7eg19556f9e5e004275@mail.gmail.com> On 5/17/07, Ralf Corsepius wrote: > > This could at least stabilize things for F7 -- everything is present > > the way it was in fc6, > Exactly: No progress. > > Development-wise a step backwards. At least this way we'd get a chance to take a breath, address concerns that a number of people have with this, and plan for F8 in a sensible way. -Chris -- Chris Weyl Ex astris, scientia From rc040203 at freenet.de Thu May 17 17:18:07 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 17 May 2007 19:18:07 +0200 Subject: More on perl for F7 In-Reply-To: <7dd7ab490705171009m56f46f7eg19556f9e5e004275@mail.gmail.com> References: <7dd7ab490705170817h1c048409k60f774b126a3dd87@mail.gmail.com> <1179416166.4735.833.camel@mccallum.corsepiu.local> <7dd7ab490705171009m56f46f7eg19556f9e5e004275@mail.gmail.com> Message-ID: <1179422288.4735.863.camel@mccallum.corsepiu.local> On Thu, 2007-05-17 at 10:09 -0700, Chris Weyl wrote: > On 5/17/07, Ralf Corsepius wrote: > > > This could at least stabilize things for F7 -- everything is present > > > the way it was in fc6, > > Exactly: No progress. > > > > Development-wise a step backwards. > > At least this way we'd get a chance to take a breath, address concerns > that a number of people have with this, and plan for F8 in a sensible > way. Red Hat, you've had all of your chances in your hands, but you missed them - once again. Ralf From rnorwood at redhat.com Thu May 17 23:23:22 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 17 May 2007 19:23:22 -0400 Subject: More on perl for F7 In-Reply-To: <1179372253.4735.785.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Thu, 17 May 2007 05:24:12 +0200") References: <1179372253.4735.785.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Wed, 2007-05-16 at 11:32 -0400, Robin Norwood wrote: >> Hi, >> >> We've been discussing the perl split and how to minimize disruption for >> users. Warren, spot, and I are seeing about getting the 'core' perl >> packages that have been split into separate RPMs added to the list of >> packages that get installed by default whenever perl is installed. This >> way, most users will still have CPAN + co, but we'll still have most of >> the advantages we wanted from splitting them out in the first place. >> >> This basically changes the 'build/devel' related perl modules from >> opt-in to opt-out for F7. >> >> What do you think? > Wrong move. > > This renders perl-devel into a meta-package and voids/avoids forcing > users to use full BuildRequires. > > I.e. this widely spoils and voids one fundamental aspect the split is > aiming at. I agree, to a point - however, with all this happening so late in the cycle, many people were annoyed at how impactful the changes would be. It's even too late for release notes, so we couldn't hide behind the 'but it was in the release notes...you *did* read the release notes, right?' defense. This way we get to keep the split, and we can remove the packages from the default install early in the F8 dev cycle, giving us more time to warn/badger perl module owners. -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 May 18 12:05:33 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 08:05:33 -0400 Subject: [Bug 240540] New: perl-5.8.8-17.fc7 omits libperl.so 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=240540 Summary: perl-5.8.8-17.fc7 omits libperl.so Product: Fedora Core Version: test4 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: M.A.Young at durham.ac.uk QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com I have just upgraded to perl-5.8.8-17.fc7 and now whenever I try to run perl I get the error perl: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory It seems this build of perl is missing some crucial 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 rnorwood at redhat.com Fri May 18 13:41:51 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 18 May 2007 09:41:51 -0400 Subject: More on perl for F7 In-Reply-To: <1179422288.4735.863.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Thu, 17 May 2007 19:18:07 +0200") References: <7dd7ab490705170817h1c048409k60f774b126a3dd87@mail.gmail.com> <1179416166.4735.833.camel@mccallum.corsepiu.local> <7dd7ab490705171009m56f46f7eg19556f9e5e004275@mail.gmail.com> <1179422288.4735.863.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Thu, 2007-05-17 at 10:09 -0700, Chris Weyl wrote: >> On 5/17/07, Ralf Corsepius wrote: >> > > This could at least stabilize things for F7 -- everything is present >> > > the way it was in fc6, >> > Exactly: No progress. >> > >> > Development-wise a step backwards. >> >> At least this way we'd get a chance to take a breath, address concerns >> that a number of people have with this, and plan for F8 in a sensible >> way. > > Red Hat, you've had all of your chances in your hands, but you > missed them - once again. It's a compromise. It's not perfect, but it makes forward progress without annoying too many people. Like I said, we can work on fixing it better early in the F8 cycle this time, rather than so late in the F7 cycle. And, don't say "Red Hat" - that's pointless, because there's no personal responsibility when you blame an entire company. If you want to point fingers, blame me, because it was my call. -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 May 18 13:44:40 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 09:44:40 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181344.l4IDieL9012792@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From rnorwood at redhat.com 2007-05-18 09:44 EST ------- That's odd - for -17, we moved libperl.so into perl-libs - I thought perl-libs would be pulled in...it seemed to on my box. How did you install -17? Yum? -- 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 May 18 13:54:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 09:54:52 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181354.l4IDsqkx013656@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From rnorwood at redhat.com 2007-05-18 09:54 EST ------- Very strange - the deps seem ok to me... perl requires libperl.so perl-libs provide libperl.so Nothing else provides libperl.so We're looking into it, 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 Fri May 18 13:58:27 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 09:58:27 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181358.l4IDwRCN013914@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From rnorwood at redhat.com 2007-05-18 09:58 EST ------- Oh, and I should mention that installing perl-libs by hand will work around this problem. -- 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 May 18 14:04:35 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 10:04:35 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181404.l4IE4ZCi014479@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From M.A.Young at durham.ac.uk 2007-05-18 10:04 EST ------- I rolled back to -15 and repeated it, and it worked this time. I think I might have had two versions of perl installed beforehand due to having to abort an essentially hung upgrade from FC6, so it might just have been my slightly broken setup that triggered this. -- 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 May 18 14:11:00 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 10:11:00 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181411.l4IEB0Ba014925@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From M.A.Young at durham.ac.uk 2007-05-18 10:10 EST ------- Or yum may have been talking to an only partially upgraded mirror. Either way I suspect I was seeing a temporary or very rare occurence. -- 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 May 18 14:33:52 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 10:33:52 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181433.l4IEXqYG017075@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|rnorwood at redhat.com |skvidal at linux.duke.edu ------- Additional Comments From rnorwood at redhat.com 2007-05-18 10:33 EST ------- Weird - I've had at least one other report of this - I could maybe see the two-perls thing confusing yum, but it really shouldn't let you end up in a state with deps being left unresolved. Let me kick this over to skvidal for his input. -- 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 May 18 14:38:49 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 10:38:49 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181438.l4IEcnig017680@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From rnorwood at redhat.com 2007-05-18 10:38 EST ------- Seth, any idea what the deal is here? AFAICT, the perl deps are correct for both versions, so I don't see any problem with the perl package here. Could yum be confused? -- 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 May 18 14:41:14 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 18 May 2007 16:41:14 +0200 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: <200705181433.l4IEXqYG017075@bugzilla.redhat.com> References: <200705181433.l4IEXqYG017075@bugzilla.redhat.com> Message-ID: <1179499275.4735.995.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 10:33 -0400, 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: perl-5.8.8-17.fc7 omits libperl.so > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 > > > rnorwood at redhat.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > AssignedTo|rnorwood at redhat.com |skvidal at linux.duke.edu > > > > > ------- Additional Comments From rnorwood at redhat.com 2007-05-18 10:33 EST ------- > Weird - I've had at least one other report of this - I could maybe see the > two-perls thing confusing yum, but it really shouldn't let you end up in a state > with deps being left unresolved. Let me kick this over to skvidal for his input. Are their more than 2 versions of perl around (Either installed or inside of the repos), at least one with *-libs split out and one without? Then this could be the same (still persisting and unfixed) yum bug I had reported several times. Ralf From cweyl at alumni.drew.edu Fri May 18 16:31:35 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 18 May 2007 09:31:35 -0700 Subject: Thoughts... Message-ID: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> Hey all -- What with all the recent turmoil surrounding the Infamous Perl Split of naught-seven, I thought I'd take a few minutes and put down some of the areas in which I feel might need a little work. I don't intend for this note to spark a fire, or to be taken as anything but healthy, constructive criticism, but a solid discussion of these issues should provide for a stronger perl SIG going forward. What was the old Klingon adage? That which does not kill us makes us write more one-liners? :) * buildrequres for perl modules. Until just recently, it was considered poor form to include core perl modules as buildrequires; now for a few of them we have to. Do we want to start including all core modules as BR's, or just the ones that have been split off? Regardless, we should document this (say under PackagingDrafts/Perl). * co-maintainership. For the record, if there's something that needs to be done to any of my perl packages, I don't have a problem with it. (E.g. a coordinated effort to add the newly-missing br's to them, etc). I only ask that the minimum change necessary be made, a note be sent to this list, and a reasonable effort be made to contact me first. I rather like Ralf's idea of a "SWAT team", but I don't think it needs to be phrased as such: as a SIG cooperating together to improve the state of Perl in Fedora as a whole we can accomplish much. As we package more and more of CPAN, this is definitely an area we should examine. This leads nicely into... * infrastructure. It just struck me that we have but a fraction of the "good" CPAN modules in Fedora, and as I push towards packaging more of Catalyst etc that number is going to rise. Fortunately, CPAN itself makes keeping track of these packages (and updates, etc) much easier -- and I have a couple scripts written to, e.g., compare the version in devel and the version in CPAN, etc. If we put a little effort into it, there's no reason we couldn't create a framework to regularly check packaged versions vs CPAN versions and post the results somewhere. --say in a Fedora-hosted project. (perl.fedoraproject.org anyone? ) Such an approach would benefit us all. A cpanspec-like tool to update specs, check br's, run a build and rpmlint it to assist with updates would also make life much easier. * perl packaging guidelines could use some love. One of the things I've been becoming acutely aware of lately is that there's a large body of customs and best practices in terms of packaging perl modules that we've built up over the years. From things like "prefer Build.PL over Makefile.PL" to simple things like "It's 'GPL or Artistic', not the other way around", we have a consensus on The Reasonable Way To Package Modules. However, it's not written down anywhere :) I've been updating PackagingDrafts/Perl periodically over the last few weeks. I don't think we need to set down hard and fast rules, but a document like this, that the perl SIG take ownership of, would help communicate these best practices to newbies. * SIG communication and coordination. If there's one thing that the recent perl split has exposed, it's that there are some strong opinions about the proper way to do things, held by many people -- myself included :) In an environment like this, it's critical (IMHO) to lead up to major changes through a through and open discussion on the list (and perhaps IRC). An attempt at reaching a consensus should be given serious effort, and changes should be done in a reasonable way (e.g. in the beginning of a development cycle). Even if a consensus cannot be reached, a reasonable effort at it will help everyone accept the outcome. Very few of us here are paid to do this. We're here for a variety of reasons, all of which are valid, and because of that it's even more important for us to be engaged as a community, and to feel that we have a stake (and say!) in it. Whew! Ok. Time for more coffee :) -Chris -- Chris Weyl Ex astris, scientia From bugzilla at redhat.com Fri May 18 17:35:04 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 13:35:04 -0400 Subject: [Bug 240596] New: Perl perl-5.8.8-17.fc7 update doesn't requires perl-libs resulting in broken lib 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=240596 Summary: Perl perl-5.8.8-17.fc7 update doesn't requires perl-libs resulting in broken lib Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: high Priority: medium Component: perl AssignedTo: rnorwood at redhat.com ReportedBy: gbillios at gmail.com QAContact: dkl at redhat.com CC: fedora-perl-devel-list at redhat.com Description of problem: With the perl-5.8.8-17.fc7 update some libs like libperl.so were moves to perl-libs package but this was not installed during update resulting in some programs even perl to complain that they can't find libperl.so Version-Release number of selected component (if applicable): perl-5.8.8-17.fc7 How reproducible: always Steps to Reproduce: 1.Update from previous ver to perl-5.8.8-17.fc7 with yum 2.run eg. perl or vim 3. Actual results: can't find libperl.so Expected results: run normally Additional info: Installing manually perl-libs package solves it -- 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 May 18 17:58:25 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 13:58:25 -0400 Subject: [Bug 240596] Perl perl-5.8.8-17.fc7 update doesn't requires perl-libs resulting in broken lib In-Reply-To: Message-ID: <200705181758.l4IHwPQA006477@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 perl-5.8.8-17.fc7 update doesn't requires perl-libs resulting in broken lib https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240596 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |DUPLICATE ------- Additional Comments From rnorwood at redhat.com 2007-05-18 13:58 EST ------- *** This bug has been marked as a duplicate of 240540 *** -- 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 May 18 17:58:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 13:58:26 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705181758.l4IHwQpr006517@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 rnorwood at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gbillios at gmail.com ------- Additional Comments From rnorwood at redhat.com 2007-05-18 13:58 EST ------- *** Bug 240596 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 rnorwood at redhat.com Fri May 18 18:33:41 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 18 May 2007 14:33:41 -0400 Subject: Thoughts... In-Reply-To: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> (Chris Weyl's message of "Fri, 18 May 2007 09:31:35 -0700") References: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> Message-ID: "Chris Weyl" writes: > Hey all -- > > What with all the recent turmoil surrounding the Infamous Perl Split > of naught-seven, I thought I'd take a few minutes and put down some of > the areas in which I feel might need a little work. I don't intend > for this note to spark a fire, or to be taken as anything but healthy, > constructive criticism, but a solid discussion of these issues should > provide for a stronger perl SIG going forward. > > What was the old Klingon adage? That which does not kill us makes us > write more one-liners? :) Chris, Thanks for the ideas - responding inline. > * buildrequres for perl modules. > > Until just recently, it was considered poor form to include core perl > modules as buildrequires; now for a few of them we have to. Do we > want to start including all core modules as BR's, or just the ones > that have been split off? Regardless, we should document this (say > under PackagingDrafts/Perl). I don't know if it makes sense to include all the core modules as BR's - I think we first need to decide exactly how far this split is going, and then it will be more clear which BR need to be explicitly stated. > * co-maintainership. > > For the record, if there's something that needs to be done to any of > my perl packages, I don't have a problem with it. (E.g. a coordinated > effort to add the newly-missing br's to them, etc). I only ask that > the minimum change necessary be made, a note be sent to this list, and > a reasonable effort be made to contact me first. I rather like Ralf's > idea of a "SWAT team", but I don't think it needs to be phrased as > such: as a SIG cooperating together to improve the state of Perl in > Fedora as a whole we can accomplish much. For now, at least, list list is low-traffic enough to support the SWAT-type activities...we just need to define how we interact with the package owners, and get their buy-in/permission/forgiveness. > As we package more and more of CPAN, this is definitely an area we > should examine. > > This leads nicely into... > > * infrastructure. > > It just struck me that we have but a fraction of the "good" CPAN > modules in Fedora, and as I push towards packaging more of Catalyst > etc that number is going to rise. Fortunately, CPAN itself makes > keeping track of these packages (and updates, etc) much easier -- and > I have a couple scripts written to, e.g., compare the version in devel > and the version in CPAN, etc. If we put a little effort into it, > there's no reason we couldn't create a framework to regularly check > packaged versions vs CPAN versions and post the results somewhere. > --say in a Fedora-hosted project. (perl.fedoraproject.org anyone? > ) Such an approach would benefit us all. > > A cpanspec-like tool to update specs, check br's, run a build and > rpmlint it to assist with updates would also make life much easier. Yeah, this has been one of my back-burner ideas for awhile now, too. I don't think there's anything really magical or hard here we just need to get it on someone's front burner and get it done. I'll see about taking a stab at it in the next couple of weeks and see how far I get. > * perl packaging guidelines could use some love. > > One of the things I've been becoming acutely aware of lately is that > there's a large body of customs and best practices in terms of > packaging perl modules that we've built up over the years. From > things like "prefer Build.PL over Makefile.PL" to simple things like > "It's 'GPL or Artistic', not the other way around", we have a > consensus on The Reasonable Way To Package Modules. > > However, it's not written down anywhere :) > > I've been updating PackagingDrafts/Perl periodically over the last few > weeks. I don't think we need to set down hard and fast rules, but a > document like this, that the perl SIG take ownership of, would help > communicate these best practices to newbies. It looks pretty good to me - how would you like feedback? Shall I edit the wiki, or send you diffs? > * SIG communication and coordination. > > If there's one thing that the recent perl split has exposed, it's that > there are some strong opinions about the proper way to do things, held > by many people -- myself included :) In an environment like this, > it's critical (IMHO) to lead up to major changes through a through and > open discussion on the list (and perhaps IRC). An attempt at reaching > a consensus should be given serious effort, and changes should be done > in a reasonable way (e.g. in the beginning of a development cycle). > Even if a consensus cannot be reached, a reasonable effort at it will > help everyone accept the outcome. > > Very few of us here are paid to do this. We're here for a variety of > reasons, all of which are valid, and because of that it's even more > important for us to be engaged as a community, and to feel that we > have a stake (and say!) in it. I'll try to do better with this for F8 - unfortunately perl stuff got pushed too far out in the cycle of things I pay attention to during F7's dev cycle. A couple of things specifically I'd like to look at early in F8 in addition to your list: o Finalize 'the split' - which packages do we still want to split from perl? All of them?? If we do split everything out that we can, we probably need some sort of 'perl-core/perl-devel/perl-everything' meta-goodness. o Fix up the dependencies, (probably) remove the 'devel' rpms from the buildroots, the and anaconda set of default RPMS. - And fix the dependencies on other perl-* packages. o Remove the %perlmodcompat stuff, unless someone has a good reason to keep it. -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 Fri May 18 23:51:55 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Fri, 18 May 2007 16:51:55 -0700 Subject: Thoughts... In-Reply-To: References: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> Message-ID: <7dd7ab490705181651j14ebd5ddvfffcbf389f54e02e@mail.gmail.com> On 5/18/07, Robin Norwood wrote: > "Chris Weyl" writes: > > * buildrequres for perl modules. [...snip...] > I don't know if it makes sense to include all the core modules as BR's - > I think we first need to decide exactly how far this split is going, and > then it will be more clear which BR need to be explicitly stated. I'm inclined to steer away from BR'ing non-split core modules myself. The problem then becomes one of defining the list of split core modules and insisting on those -- but I don't think we'll have that final list locked down for, oh, a month or so I suspect. (Given F7 out and a little time for things to calm down.) I see two advantages to BR'ing all modules, core or not: * There's never a question of if something needs to be BR'ed * If we split more off in the future, we don't have to worry about adding them to all the specs > > * co-maintainership. [...snip...] > For now, at least, list list is low-traffic enough to support the > SWAT-type activities...we just need to define how we interact with the > package owners, and get their buy-in/permission/forgiveness. Yeah. Ideally the distinction would be SIG members vs random maintainer who just happens to have a perl package (e.g. people who care about perl in Fedora as a whole vs people who just care about their packages). Ideally we'd be able to help manage major changes (like the split) as well as cover for each other when life / Real Job / etc takes precedence. (Happens to all of us from time to time.) This is something that appropriate infrastructure can facilitate and enable. > > * infrastructure. [...snip...] > Yeah, this has been one of my back-burner ideas for awhile now, too. I > don't think there's anything really magical or hard here we just need to > get it on someone's front burner and get it done. I'll see about taking > a stab at it in the next couple of weeks and see how far I get. I suspect there are several of us who have already written some variant of a "check version against CPAN" script out there; it might just be possible to modify one (or more) of those to run periodically and stick the output into a wiki page / email / custom page / etc somewhere. As an aside, I'm certainly willing to help out with writing / implementing these tools. Actually, if I have some free time this weekend maybe I'll take a first pass at adapting my check-cpan script to dump out a static page and post it somewhere for people to critique. I also have a (horribly messy) script to handle the gruntwork of putting a package up for review: ftp'ing it somewhere, creating the review bug; posting long reviews and toggling flags. It uses the bugzilla xml-rpc commands (that I know of, at least) to perform these functions. I'll see if I can't clean it up some and get it out there... If anyone knows more about the xml-rpc interface to bugzilla, I'd be very interested in hearing about it :) > > * perl packaging guidelines could use some love. [...snip...] > It looks pretty good to me - how would you like feedback? Shall I edit > the wiki, or send you diffs? Excellent :) Whatever you feel is most appropriate -- it is a wiki, so I don't see any reason why we all can't just edit it directly. > > * SIG communication and coordination. [...snip...] > I'll try to do better with this for F8 - unfortunately perl stuff got > pushed too far out in the cycle of things I pay attention to during F7's > dev cycle. No worries. Again, I'm not criticizing anyone in particular, but rather trying to offer some feedback as we go forward. > A couple of things specifically I'd like to look at early in F8 in > addition to your list: > > o Finalize 'the split' - which packages do we still want to split from > perl? All of them?? If we do split everything out that we can, we > probably need some sort of 'perl-core/perl-devel/perl-everything' > meta-goodness. > > o Fix up the dependencies, (probably) remove the 'devel' rpms from the > buildroots, the and anaconda set of default RPMS. > > - And fix the dependencies on other perl-* packages. > > o Remove the %perlmodcompat stuff, unless someone has a good reason to > keep it. Sounds good by me :) -Chris -- Chris Weyl Ex astris, scientia From bugzilla at redhat.com Fri May 18 23:58:04 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 19:58:04 -0400 Subject: [Bug 234934] BR Affix::Infix2Postfix and Image::Math::Constrain for better test coverage In-Reply-To: Message-ID: <200705182358.l4INw4FE001438@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: BR Affix::Infix2Postfix and Image::Math::Constrain for better test coverage https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234934 Bug 234934 depends on bug 234939, which changed state. Bug 234939 Summary: Review Request: perl-Affix-Infix2Postfix - Perl extension for converting from infix notation to postfix notation https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234939 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE 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 May 18 23:58:28 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 19:58:28 -0400 Subject: [Bug 234934] BR Affix::Infix2Postfix and Image::Math::Constrain for better test coverage In-Reply-To: Message-ID: <200705182358.l4INwSFK001485@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: BR Affix::Infix2Postfix and Image::Math::Constrain for better test coverage https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234934 Bug 234934 depends on bug 234940, which changed state. Bug 234940 Summary: Review Request: perl-Image-Math-Constrain - Scaling math used in image size constraining (such as thumbnails) https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234940 What |Old Value |New Value ---------------------------------------------------------------------------- Resolution| |NEXTRELEASE 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 Sat May 19 01:01:01 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 18 May 2007 21:01:01 -0400 Subject: [Bug 234934] BR Affix::Infix2Postfix and Image::Math::Constrain for better test coverage In-Reply-To: Message-ID: <200705190101.l4J111OV003073@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: BR Affix::Infix2Postfix and Image::Math::Constrain for better test coverage https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=234934 steve at silug.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NEXTRELEASE ------- Additional Comments From steve at silug.org 2007-05-18 21:00 EST ------- Added in perl-Imager 0.58-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 Sat May 19 04:20:27 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sat, 19 May 2007 06:20:27 +0200 Subject: Thoughts... In-Reply-To: References: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> Message-ID: <1179548427.4735.1073.camel@mccallum.corsepiu.local> On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote: > "Chris Weyl" writes: > > > Hey all -- > > > > What with all the recent turmoil surrounding the Infamous Perl Split > > of naught-seven, I thought I'd take a few minutes and put down some of > > the areas in which I feel might need a little work. I don't intend > > for this note to spark a fire, or to be taken as anything but healthy, > > constructive criticism, but a solid discussion of these issues should > > provide for a stronger perl SIG going forward. > > > > What was the old Klingon adage? That which does not kill us makes us > > write more one-liners? :) > > Chris, > > Thanks for the ideas - responding inline. > > > * buildrequres for perl modules. > > > > Until just recently, it was considered poor form to include core perl > > modules as buildrequires; now for a few of them we have to. Do we > > want to start including all core modules as BR's, or just the ones > > that have been split off? Regardless, we should document this (say > > under PackagingDrafts/Perl). > > I don't know if it makes sense to include all the core modules as BR's - It does, because this is the only way to guarantee long term stability. IMO, the confusion you see know largely is only a side-effect of the perl-module packaging having been "too lax" so far. If all perl-modules packaging would have applied stricter rules, you'd be able to move perl-core modules between packages, and nobody would have noticed. "BR-ing core-modules in *.specs", in practice condenses to a handful of modules, namely those explicitly required by a module's build infrastructure. Anything else will be pulled in automatically. > I think we first need to decide exactly how far this split is going, and > then it will be more clear which BR need to be explicitly stated. ... We would have had opportunities to gain clarity, if you had not reverted the split. Now, I can only urge you to revert your recent changes for rawhide (F8) ASAP. > > * co-maintainership. > > > > For the record, if there's something that needs to be done to any of > > my perl packages, I don't have a problem with it. (E.g. a coordinated > > effort to add the newly-missing br's to them, etc). I only ask that > > the minimum change necessary be made, a note be sent to this list, and > > a reasonable effort be made to contact me first. I rather like Ralf's > > idea of a "SWAT team", but I don't think it needs to be phrased as > > such: as a SIG cooperating together to improve the state of Perl in > > Fedora as a whole we can accomplish much. > > For now, at least, list list is low-traffic enough to support the > SWAT-type activities...we just need to define how we interact with the > package owners, and get their buy-in/permission/forgiveness. Well, meanwhile, given how the merger changes Fedora's workflow, I am not sure anymore if a "SWAT" team can work. Things which had been easy before (and to some extend could have been scripted), now seem to become inapplicable ... > > As we package more and more of CPAN, this is definitely an area we > > should examine. > > > > This leads nicely into... > > > > * infrastructure. > > > > It just struck me that we have but a fraction of the "good" CPAN > > modules in Fedora, and as I push towards packaging more of Catalyst > > etc that number is going to rise. Fortunately, CPAN itself makes > > keeping track of these packages (and updates, etc) much easier -- and > > I have a couple scripts written to, e.g., compare the version in devel > > and the version in CPAN, etc. If we put a little effort into it, > > there's no reason we couldn't create a framework to regularly check > > packaged versions vs CPAN versions and post the results somewhere. > > --say in a Fedora-hosted project. (perl.fedoraproject.org anyone? > > ) Such an approach would benefit us all. > > > > A cpanspec-like tool to update specs, check br's, run a build and > > rpmlint it to assist with updates would also make life much easier. > > Yeah, this has been one of my back-burner ideas for awhile now, too. I > don't think there's anything really magical or hard here we just need to > get it on someone's front burner and get it done. I'll see about taking > a stab at it in the next couple of weeks and see how far I get. Steven Pritchard has/had a couple of nice scripts. > > * perl packaging guidelines could use some love. > > > > One of the things I've been becoming acutely aware of lately is that > > there's a large body of customs and best practices in terms of > > packaging perl modules that we've built up over the years. From > > things like "prefer Build.PL over Makefile.PL" to simple things like > > "It's 'GPL or Artistic', not the other way around", we have a > > consensus on The Reasonable Way To Package Modules. > > > > However, it's not written down anywhere :) Is there a need to do so? I don't think so. Build.PL or Makefile.PL should not matter at all (It matters that a package builds) - Some CPAN authors prefer Build.PL, I hate it and consider it to be "mal-designed junk". We have other "semi-written rules" which are much more of importance (e.g. perl modules must own all dirs not owned by the "perl" or "filesystem" packages). > > * SIG communication and coordination. > > > > If there's one thing that the recent perl split has exposed, it's that > > there are some strong opinions about the proper way to do things, held > > by many people -- myself included :) In an environment like this, > > it's critical (IMHO) to lead up to major changes through a through and > > open discussion on the list (and perhaps IRC). An attempt at reaching > > a consensus should be given serious effort, and changes should be done > > in a reasonable way (e.g. in the beginning of a development cycle). > > Even if a consensus cannot be reached, a reasonable effort at it will > > help everyone accept the outcome. > > > > Very few of us here are paid to do this. We're here for a variety of > > reasons, all of which are valid, and because of that it's even more > > important for us to be engaged as a community, and to feel that we > > have a stake (and say!) in it. > > I'll try to do better with this for F8 Glad to hear you say this - I am pretty disappointed about seeing the split effectively having been reverted, last minute. Changes, I had invested quite some considerable time in, because I had thought you were aiming at getting them into FC7 - Apparently, I was wrong. > - unfortunately perl stuff got > pushed too far out in the cycle of things I pay attention to during F7's > dev cycle. > > A couple of things specifically I'd like to look at early in F8 in > addition to your list: > > o Finalize 'the split' - which packages do we still want to split from > perl? All of them?? If we do split everything out that we can, we > probably need some sort of 'perl-core/perl-devel/perl-everything' > meta-goodness. The split should be focused on separating "*devel" from "runtime". That was the motivation to split out "MakeMaker", CPAN, and Test:: modules (*devel packages). > o Fix up the dependencies, (probably) remove the 'devel' rpms from the > buildroots, the and anaconda set of default RPMS. > > - And fix the dependencies on other perl-* packages. > > o Remove the %perlmodcompat stuff, unless someone has a good reason to > keep it. * Clean up rpm not to provide bogus libXXX.so's on perl's dynamically loaded *.so. Probably all of them are "plain wrong". Ralf From bugzilla at redhat.com Sat May 19 04:25:43 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sat, 19 May 2007 00:25:43 -0400 Subject: [Bug 240640] New: Please update 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=240640 Summary: Please update Product: Fedora Extras Version: fc6 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-File-RsyncP AssignedTo: mmcgrath at redhat.com ReportedBy: johan at x-tnd.be QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com Upstream released 0.68 on november 2006. Any plans to update ? I need 0.68 to run BackupPC 3.0 -- 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 Sat May 19 20:04:56 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Sat, 19 May 2007 16:04:56 -0400 Subject: Thoughts... In-Reply-To: <1179548427.4735.1073.camel@mccallum.corsepiu.local> (Ralf Corsepius's message of "Sat, 19 May 2007 06:20:27 +0200") References: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> <1179548427.4735.1073.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius writes: > On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote: >> "Chris Weyl" writes: >> I don't know if it makes sense to include all the core modules as BR's - > > It does, because this is the only way to guarantee long term stability. > IMO, the confusion you see know largely is only a side-effect of the > perl-module packaging having been "too lax" so far. If all perl-modules > packaging would have applied stricter rules, you'd be able to move > perl-core modules between packages, and nobody would have noticed. > > "BR-ing core-modules in *.specs", in practice condenses to a handful of > modules, namely those explicitly required by a module's build > infrastructure. Anything else will be pulled in automatically. I think we need to decide exactly what the goal is with splitting out the core modules - some people think we should split them all out, others want a smaller set. I'm not really sure which is best at the moment...I think it requires more discussion. >> I think we first need to decide exactly how far this split is going, and >> then it will be more clear which BR need to be explicitly stated. > ... We would have had opportunities to gain clarity, if you had not > reverted the split. This isn't actually true. The modules are still split out. The changes were to make the perl-devel require the other split modules, and include the split modules in the default install. You can still remove perl-devel + co at install time or later, if you wish. And yes, this is two steps forward, one step back. I wasn't really very happy with it, but enough people were going to be negatively impacted by this change that spot and I both decided it would be best to go this way. I would rather have made a clean split instead of doing it this way, but I have to accept that we didn't give enough warning to make people comfortable with this change. > Now, I can only urge you to revert your recent changes for rawhide (F8) > ASAP. I agree. I'll look at it Monday, unless one of the co-maintainers gets to it first. :-) >> > * co-maintainership. >> > >> > For the record, if there's something that needs to be done to any of >> > my perl packages, I don't have a problem with it. (E.g. a coordinated >> > effort to add the newly-missing br's to them, etc). I only ask that >> > the minimum change necessary be made, a note be sent to this list, and >> > a reasonable effort be made to contact me first. I rather like Ralf's >> > idea of a "SWAT team", but I don't think it needs to be phrased as >> > such: as a SIG cooperating together to improve the state of Perl in >> > Fedora as a whole we can accomplish much. >> >> For now, at least, list list is low-traffic enough to support the >> SWAT-type activities...we just need to define how we interact with the >> package owners, and get their buy-in/permission/forgiveness. > Well, meanwhile, given how the merger changes Fedora's workflow, I am > not sure anymore if a "SWAT" team can work. Things which had been easy > before (and to some extend could have been scripted), now seem to become > inapplicable ... I'm not really sure what you mean here...what specific problems do you see? [...] >> Yeah, this has been one of my back-burner ideas for awhile now, too. I >> don't think there's anything really magical or hard here we just need to >> get it on someone's front burner and get it done. I'll see about taking >> a stab at it in the next couple of weeks and see how far I get. > Steven Pritchard has/had a couple of nice scripts. Yeah, I believe I've seen them on the wiki. >> > * perl packaging guidelines could use some love. >> > >> > One of the things I've been becoming acutely aware of lately is that >> > there's a large body of customs and best practices in terms of >> > packaging perl modules that we've built up over the years. From >> > things like "prefer Build.PL over Makefile.PL" to simple things like >> > "It's 'GPL or Artistic', not the other way around", we have a >> > consensus on The Reasonable Way To Package Modules. >> > >> > However, it's not written down anywhere :) > Is there a need to do so? I don't think so. > > Build.PL or Makefile.PL should not matter at all (It matters that a > package builds) - Some CPAN authors prefer Build.PL, I hate it and > consider it to be "mal-designed junk". > > We have other "semi-written rules" which are much more of importance > (e.g. perl modules must own all dirs not owned by the "perl" or > "filesystem" packages). I think documented best practices are a good idea - if there's debate between possible options, we can present both of them along with pros and cons. >> > * SIG communication and coordination. >> > >> > If there's one thing that the recent perl split has exposed, it's that >> > there are some strong opinions about the proper way to do things, held >> > by many people -- myself included :) In an environment like this, >> > it's critical (IMHO) to lead up to major changes through a through and >> > open discussion on the list (and perhaps IRC). An attempt at reaching >> > a consensus should be given serious effort, and changes should be done >> > in a reasonable way (e.g. in the beginning of a development cycle). >> > Even if a consensus cannot be reached, a reasonable effort at it will >> > help everyone accept the outcome. >> > >> > Very few of us here are paid to do this. We're here for a variety of >> > reasons, all of which are valid, and because of that it's even more >> > important for us to be engaged as a community, and to feel that we >> > have a stake (and say!) in it. >> >> I'll try to do better with this for F8 > Glad to hear you say this - I am pretty disappointed about seeing the > split effectively having been reverted, last minute. Again, they weren't reverted - though I take your point that including them default is practically the same thing. > Changes, I had invested quite some considerable time in, because I had > thought you were aiming at getting them into FC7 - Apparently, I was > wrong. I had planned to, but was convinced that the disruption to users and developers would be too great. I probably should've brought you into the discussion, considering the contributions you'd made. Sorry! >> - unfortunately perl stuff got >> pushed too far out in the cycle of things I pay attention to during F7's >> dev cycle. >> >> A couple of things specifically I'd like to look at early in F8 in >> addition to your list: >> >> o Finalize 'the split' - which packages do we still want to split from >> perl? All of them?? If we do split everything out that we can, we >> probably need some sort of 'perl-core/perl-devel/perl-everything' >> meta-goodness. > The split should be focused on separating "*devel" from "runtime". > > That was the motivation to split out "MakeMaker", CPAN, and Test:: > modules (*devel packages). That's my gut feeling about it - but some people seem to think it would be worthwhile to split out everything. That approach would make it easier to update 'core' module piecemeal if needed to fix bugs - but leads to a lot of packages to have a 'core' perl distribution in Fedora. So, I think more discussion is warrented. >> o Fix up the dependencies, (probably) remove the 'devel' rpms from the >> buildroots, the and anaconda set of default RPMS. >> >> - And fix the dependencies on other perl-* packages. >> >> o Remove the %perlmodcompat stuff, unless someone has a good reason to >> keep it. > > * Clean up rpm not to provide bogus libXXX.so's on perl's dynamically > loaded *.so. Probably all of them are "plain wrong". Ok. I think we have a pretty good hit list going here. I'll put them up on the wiki somewhere this weekend. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rc040203 at freenet.de Sun May 20 06:09:19 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 20 May 2007 08:09:19 +0200 Subject: Thoughts... In-Reply-To: References: <7dd7ab490705180931j1fc0e4dav94f13249e80f51ca@mail.gmail.com> <1179548427.4735.1073.camel@mccallum.corsepiu.local> Message-ID: <1179641360.4735.1167.camel@mccallum.corsepiu.local> On Sat, 2007-05-19 at 16:04 -0400, Robin Norwood wrote: > Ralf Corsepius writes: > > > On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote: > >> "Chris Weyl" writes: > >> I don't know if it makes sense to include all the core modules as BR's - > > > > It does, because this is the only way to guarantee long term stability. > > IMO, the confusion you see know largely is only a side-effect of the > > perl-module packaging having been "too lax" so far. If all perl-modules > > packaging would have applied stricter rules, you'd be able to move > > perl-core modules between packages, and nobody would have noticed. > > > > "BR-ing core-modules in *.specs", in practice condenses to a handful of > > modules, namely those explicitly required by a module's build > > infrastructure. Anything else will be pulled in automatically. > > I think we need to decide exactly what the goal is with splitting out > the core modules - some people think we should split them all out, > others want a smaller set. I'm not really sure which is best at the > moment...I think it requires more discussion. > > >> I think we first need to decide exactly how far this split is going, and > >> then it will be more clear which BR need to be explicitly stated. > > ... We would have had opportunities to gain clarity, if you had not > > reverted the split. > > This isn't actually true. The modules are still split out. You have effectively reverted the split. > The changes > were to make the perl-devel require the other split modules, and include > the split modules in the default install. Exactly this is the reversion - Forcing "module'ed" BR's and R's to gain long term packaging stability was one of the prime objectives. Now, you're allowing people to continue their sloppy (bad) habits. > >> > * co-maintainership. > >> > > >> > For the record, if there's something that needs to be done to any of > >> > my perl packages, I don't have a problem with it. (E.g. a coordinated > >> > effort to add the newly-missing br's to them, etc). I only ask that > >> > the minimum change necessary be made, a note be sent to this list, and > >> > a reasonable effort be made to contact me first. I rather like Ralf's > >> > idea of a "SWAT team", but I don't think it needs to be phrased as > >> > such: as a SIG cooperating together to improve the state of Perl in > >> > Fedora as a whole we can accomplish much. > >> > >> For now, at least, list list is low-traffic enough to support the > >> SWAT-type activities...we just need to define how we interact with the > >> package owners, and get their buy-in/permission/forgiveness. > > Well, meanwhile, given how the merger changes Fedora's workflow, I am > > not sure anymore if a "SWAT" team can work. Things which had been easy > > before (and to some extend could have been scripted), now seem to become > > inapplicable ... > > I'm not really sure what you mean here...what specific problems do you > see? You aren't subscribed to maintainers@? Then you'd better be. > > Changes, I had invested quite some considerable time in, because I had > > thought you were aiming at getting them into FC7 - Apparently, I was > > wrong. > > I had planned to, but was convinced that the disruption to users and > developers would be too great. I probably should've brought you into > the discussion, considering the contributions you'd made. Sorry! OSS development is based on "give and take" ... You will have to understand that such lonesome and lately communicated decisions drive external volunteers away. > >> - unfortunately perl stuff got > >> pushed too far out in the cycle of things I pay attention to during F7's > >> dev cycle. > >> > >> A couple of things specifically I'd like to look at early in F8 in > >> addition to your list: > >> > >> o Finalize 'the split' - which packages do we still want to split from > >> perl? All of them?? If we do split everything out that we can, we > >> probably need some sort of 'perl-core/perl-devel/perl-everything' > >> meta-goodness. > > The split should be focused on separating "*devel" from "runtime". > > > > That was the motivation to split out "MakeMaker", CPAN, and Test:: > > modules (*devel packages). > > That's my gut feeling about it - but some people seem to think it would > be worthwhile to split out everything. There likely are more modules which would make sense to be split out, but a "split out everything" would be stupid. What I think the next steps should be 1. Revert your recent changes 2. Reconsider the *-lib split. 3. Reflect this split to perl-modules. .. n. Check for further split-out candidates. Ralf From bugzilla at redhat.com Mon May 21 02:35:25 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Sun, 20 May 2007 22:35:25 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705210235.l4L2ZP3Y028086@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From Michael.Sinz at sinz.org 2007-05-20 22:35 EST ------- I can say that this also happened to me, just today. Doing the yum update ended up leaving the system with a non-functional perl. It was simple to fix since I just did a package grep for perl and lib and found the perl-libs package and installed it manually. I wonder if the fact that libperl.so was provided by the -15 version and then was not in -17 somehow messed up the dependency check? I will see if I can find the time to do a fresh install from FC7test4 and then update again. (Maybe sometime this week) -- 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 curoli at gmail.com Mon May 21 16:08:17 2007 From: curoli at gmail.com (Oliver Ruebenacker) Date: Mon, 21 May 2007 12:08:17 -0400 Subject: Template-XML Message-ID: <5639badd0705210908s5d5e0c7bw88c6c274f9803524@mail.gmail.com> Dear friends, Do you have Template-XML as RPM for Fedora 6 and 7? I have been told I need it to make the XML.DOM plugin work for the Perl Template Toolkit, and that I should send a request to this list. Thanks! Take care Oliver -- Oliver Ruebenacker, Post-Doc Researcher Theoretical Biological Physics and Soft Statistical Mechanics Cell Biology at UConn Health Center and Physics at Harvard http://people.deas.harvard.edu/~oliver/ From bugzilla at redhat.com Mon May 21 17:58:38 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 21 May 2007 13:58:38 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705211758.l4LHwcTx023007@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From jdaytona at gmail.com 2007-05-21 13:58 EST ------- Also happened to me last week. yum install perl-libs solved the 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 rnorwood at redhat.com Mon May 21 19:02:45 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 21 May 2007 15:02:45 -0400 Subject: Thoughts... Message-ID: Sorry, I'm probably breaking threading here...my main work laptop went down, and I managed to fumble a command and lost some mail. Ralf Corsepius writes: >On Sat, 2007-05-19 at 16:04 -0400, Robin Norwood wrote: >> Ralf Corsepius writes: >> > ... We would have had opportunities to gain clarity, if you had not >> > reverted the split. >> >> This isn't actually true. The modules are still split out. >You have effectively reverted the split. > >> The changes >> were to make the perl-devel require the other split modules, and include >> the split modules in the default install. >Exactly this is the reversion - Forcing "module'ed" BR's and R's to gain >long term packaging stability was one of the prime objectives. > >Now, you're allowing people to continue their sloppy (bad) habits. Yes, I agree, it wasn't as much progress as we wanted. But it was sufficiently annoying to some people, that I agreed with the logic that these changes were too much, too late. [...] >> >> For now, at least, list list is low-traffic enough to support the >> >> SWAT-type activities...we just need to define how we interact with the >> >> package owners, and get their buy-in/permission/forgiveness. >> > Well, meanwhile, given how the merger changes Fedora's workflow, I am >> > not sure anymore if a "SWAT" team can work. Things which had been easy >> > before (and to some extend could have been scripted), now seem to become >> > inapplicable ... >> >> I'm not really sure what you mean here...what specific problems do you >> see? >You aren't subscribed to maintainers ? Then you'd better be. I am, but apparently hadn't followed it as closely as I should have. [...] >> I had planned to, but was convinced that the disruption to users and >> developers would be too great. I probably should've brought you into >> the discussion, considering the contributions you'd made. Sorry! >OSS development is based on "give and take" ... You will have to >understand that such lonesome and lately communicated decisions drive >external volunteers away. And other contributors were equally annoyed that we were making the change at all. [...] >> That's my gut feeling about it - but some people seem to think it would >> be worthwhile to split out everything. > >There likely are more modules which would make sense to be split out, >but a "split out everything" would be stupid. I don't see the point, either, but maybe someone will speak up who advocates it. >What I think the next steps should be >1. Revert your recent changes For F8, I'd like to do that as early as possible. >2. Reconsider the *-lib split. Consensus among various fedora-devel people seems to disagree with you. >3. Reflect this split to perl-modules. >.. >n. Check for further split-out candidates. I agree. Thanks, -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From steve at silug.org Mon May 21 19:13:42 2007 From: steve at silug.org (Steven Pritchard) Date: Mon, 21 May 2007 14:13:42 -0500 Subject: Template-XML In-Reply-To: <5639badd0705210908s5d5e0c7bw88c6c274f9803524@mail.gmail.com> References: <5639badd0705210908s5d5e0c7bw88c6c274f9803524@mail.gmail.com> Message-ID: <20070521191342.GA27251@osiris.silug.org> On Mon, May 21, 2007 at 12:08:17PM -0400, Oliver Ruebenacker wrote: > Do you have Template-XML as RPM for Fedora 6 and 7? It doesn't seem to be available yet. > I have been told I need it to make the XML.DOM plugin work for the > Perl Template Toolkit, and that I should send a request to this list. You can wait for someone else to package it, but if you want it quickly, you can do this: yum install cpanspec cpanspec -v -b Template::Plugin::XML That will get you a package you can use. If you want to submit the generated package for everyone's benefit (after some minor cleanup, of course), see the following page: http://fedoraproject.org/wiki/PackageMaintainers/Join 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 curoli at gmail.com Mon May 21 19:36:06 2007 From: curoli at gmail.com (Oliver Ruebenacker) Date: Mon, 21 May 2007 15:36:06 -0400 Subject: Template-XML In-Reply-To: <20070521191342.GA27251@osiris.silug.org> References: <5639badd0705210908s5d5e0c7bw88c6c274f9803524@mail.gmail.com> <20070521191342.GA27251@osiris.silug.org> Message-ID: <5639badd0705211236u33d1b3e8pd0cbc150cc85140a@mail.gmail.com> Dear friends, Tried, but got these errors: BEGIN failed--compilation aborted at t/xpath.t line 21. t/xpath........dubious Test returned status 2 (wstat 512, 0x200) FAILED--8 test scripts could be run, alas--no output ever seen make: *** [test_dynamic] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.17975 (%check) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.17975 (%check) /usr/bin/rpmbuild exited with value 1 How should I proceed? Thanks! Take care Oliver On 5/21/07, Steven Pritchard wrote: > On Mon, May 21, 2007 at 12:08:17PM -0400, Oliver Ruebenacker wrote: > > Do you have Template-XML as RPM for Fedora 6 and 7? > > It doesn't seem to be available yet. > > > I have been told I need it to make the XML.DOM plugin work for the > > Perl Template Toolkit, and that I should send a request to this list. > > You can wait for someone else to package it, but if you want it > quickly, you can do this: > > yum install cpanspec > cpanspec -v -b Template::Plugin::XML > > That will get you a package you can use. If you want to submit the > generated package for everyone's benefit (after some minor cleanup, of > course), see the following page: > > http://fedoraproject.org/wiki/PackageMaintainers/Join > > 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 > -- Oliver Ruebenacker, Post-Doc Researcher Theoretical Biological Physics and Soft Statistical Mechanics Cell Biology at UConn Health Center and Physics at Harvard http://people.deas.harvard.edu/~oliver/ From dave at dave.org.uk Mon May 21 20:00:01 2007 From: dave at dave.org.uk (Dave Cross) Date: Mon, 21 May 2007 21:00:01 +0100 Subject: Template-XML In-Reply-To: <5639badd0705211236u33d1b3e8pd0cbc150cc85140a@mail.gmail.com> References: <5639badd0705210908s5d5e0c7bw88c6c274f9803524@mail.gmail.com> <20070521191342.GA27251@osiris.silug.org> <5639badd0705211236u33d1b3e8pd0cbc150cc85140a@mail.gmail.com> Message-ID: <4651FA41.5010305@dave.org.uk> Oliver Ruebenacker wrote: > Dear friends, > > Tried, but got these errors: > > BEGIN failed--compilation aborted at t/xpath.t line 21. > t/xpath........dubious > Test returned status 2 (wstat 512, 0x200) > FAILED--8 test scripts could be run, alas--no output ever seen > make: *** [test_dynamic] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.17975 (%check) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.17975 (%check) > /usr/bin/rpmbuild exited with value 1 > > How should I proceed? Thanks! Worked ok here. RPM: http://rpm.mag-sol.com/RPMS/perl-Template-XML-2.17-1.noarch.rpm SRPM: http://rpm.mag-sol.com/SRPMS/perl-Template-XML-2.17-1.src.rpm SPEC: http://rpm.mag-sol.com/SPECS/perl-Template-XML.spec Enjoy, Dave... From steve at silug.org Mon May 21 21:42:55 2007 From: steve at silug.org (Steven Pritchard) Date: Mon, 21 May 2007 16:42:55 -0500 Subject: Template-XML In-Reply-To: <5639badd0705211236u33d1b3e8pd0cbc150cc85140a@mail.gmail.com> References: <5639badd0705210908s5d5e0c7bw88c6c274f9803524@mail.gmail.com> <20070521191342.GA27251@osiris.silug.org> <5639badd0705211236u33d1b3e8pd0cbc150cc85140a@mail.gmail.com> Message-ID: <20070521214255.GA30005@osiris.silug.org> On Mon, May 21, 2007 at 03:36:06PM -0400, Oliver Ruebenacker wrote: > Tried, but got these errors: > > BEGIN failed--compilation aborted at t/xpath.t line 21. > t/xpath........dubious > Test returned status 2 (wstat 512, 0x200) > FAILED--8 test scripts could be run, alas--no output ever seen > make: *** [test_dynamic] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.17975 (%check) If I had to guess, try adding "BuildRequires: perl(Template)" to the spec (and installing perl-Template-Toolkit). 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 Mon May 21 22:13:25 2007 From: rc040203 at freenet.de (Ralf Corsepius) Date: Tue, 22 May 2007 00:13:25 +0200 Subject: Thoughts... In-Reply-To: References: Message-ID: <1179785605.4735.1324.camel@mccallum.corsepiu.local> On Mon, 2007-05-21 at 15:02 -0400, Robin Norwood wrote: > >2. Reconsider the *-lib split. > > Consensus among various fedora-devel people seems to disagree with you. Then please describe in detail which issues _this_ split is solving. I don't see any. Ralf From bugzilla at redhat.com Mon May 21 23:47:21 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 21 May 2007 19:47:21 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705212347.l4LNlL3q022183@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From jwulf at redhat.com 2007-05-21 19:47 EST ------- +1 on jdaytona's situation. -- 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 Tue May 22 02:49:26 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Mon, 21 May 2007 22:49:26 -0400 Subject: [Bug 214709] Date::Manip unable to determine TimeZone. In-Reply-To: Message-ID: <200705220249.l4M2nQW3031943@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: Date::Manip unable to determine TimeZone. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=214709 bugzilla at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|normal |medium ------- Additional Comments From niceckng at gmail.com 2007-05-21 22:49 EST ------- Redhat EL 5 and perl-DateManip-5.44-1.2.1 having same error on /etc/cron.daily/0logwatch. Time zone is "Asia/Kuala_Lumpur" (GMT+8). -- 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 cweyl at alumni.drew.edu Tue May 22 04:32:51 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 21 May 2007 21:32:51 -0700 Subject: Fedora to CPAN mapping... Message-ID: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> Hey all -- So I took a first shot at a "Fedora to CPAN" mapping script. It's extremely basic right now, and I blatantly stole the page style from cvs.fedora.redhat.com and the icons from the wiki. However, the table itself is at the point where I thought I'd throw it out there for feedback. Release early, release often, right? A couple caveats: * packages / owners are pulled from owners.list in cvs * package version in Fedora is determined via the spec, also pulled from cvs * I have a widescreen monitor, so the table may be too wide for some * core packages ( < F-7 ) aren't taken into account Pulling from cvs isn't optimal, but it works for now. There's still a bunch more to be done, e.g.: * a "quicklink" to open bugs (rt and bz) * overall statistics would be neat * per-owner statistics would also be neat * something to make it more difficult for the email addys to be "harvested" Anyways. Suggestions, feedback, and civil criticism welcome and requested :) http://home.comcast.net/~ckweyl/test.html -Chris -- Chris Weyl Ex astris, scientia From chicks at chicks.net Tue May 22 12:24:08 2007 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 22 May 2007 08:24:08 -0400 Subject: Fedora to CPAN mapping... In-Reply-To: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> Message-ID: <20070522122408.GB2588@chicks.net> On Mon, May 21, 2007 at 09:32:51PM -0700, Chris Weyl wrote: > So I took a first shot at a "Fedora to CPAN" mapping script. It's > extremely basic right now Impressive and handy. Thanks. It'd be nice to have a maintainer shame page where the number of out-of-date modules per owner is highlighted. If shaming doesn't encourage progress (and even if it does its not the way to motivate folks) then we can at least see how needs to have their load lightened. -- "The problem with troubleshooting is that trouble shoots back!" From bugzilla at redhat.com Tue May 22 16:54:34 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 22 May 2007 12:54:34 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705221654.l4MGsYYu005475@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From rnorwood at redhat.com 2007-05-22 12:54 EST ------- With: yum-3.0.6-1.fc6 on an up-to-date fc6 (x86) system: # yum update perl Updating: perl i386 4:5.8.8-18.fc7 development 10 M Installing for dependencies: ... perl-libs i386 4:5.8.8-18.fc7 development 571 k ... Install 18 Package(s) Update 137 Package(s) Lots of snippage, but you get the idea. If anyone has a reproducer, that would help. -- 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 Tue May 22 21:01:28 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 22 May 2007 17:01:28 -0400 Subject: [Bug 240918] New: perl-HTML-Encoding-0.53 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=240918 Summary: perl-HTML-Encoding-0.53 is available Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-HTML-Encoding 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-HTML-Encoding-0.53 is already available. Repo version is 0.52. 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 cweyl at alumni.drew.edu Wed May 23 04:07:49 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 22 May 2007 21:07:49 -0700 Subject: Fedora to CPAN mapping... In-Reply-To: <20070522122408.GB2588@chicks.net> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> Message-ID: <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> On 5/22/07, Christopher Hicks wrote: > On Mon, May 21, 2007 at 09:32:51PM -0700, Chris Weyl wrote: > > So I took a first shot at a "Fedora to CPAN" mapping script. It's > > extremely basic right now > > Impressive and handy. Thanks. > > It'd be nice to have a maintainer shame page where the number of out-of-date modules per owner is highlighted. If shaming doesn't encourage progress (and even if it does its not the way to motivate folks) then we can at least see how needs to have their load lightened. Well, I don't know if we need a "shame page"... I've found asking for updates to usually be as easy as filing a "update? pretty please?" bug. Do you see an area where we could improve as a whole in? I'm going to poke around with seeing what statistics I can generate. -Chris -- Chris Weyl Ex astris, scientia From bugzilla at redhat.com Wed May 23 12:16:16 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 23 May 2007 08:16:16 -0400 Subject: [Bug 240402] SpamAssassin sa-update gpg verification failure In-Reply-To: Message-ID: <200705231216.l4NCGGdf016401@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: SpamAssassin sa-update gpg verification failure https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240402 amessina at messinet.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |NOTABUG ------- Additional Comments From amessina at messinet.com 2007-05-23 08:16 EST ------- Closing this myself. I erred in the report. -- 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 May 23 14:03:48 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 23 May 2007 10:03:48 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705231403.l4NE3mnv026024@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From altblue at n0i.net 2007-05-23 10:03 EST ------- Wild guess (aside "funky" yum behavior): maybe those folks reporting this issue are using custom apache/mod_perl 1.x packages, with mod_perl built as DSO. Anyway, as Robin said, maybe they could double-check it with: "rpm -q --whatprovides libperl.so" and report back here if something interesting comes up. -- 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 May 23 14:20:45 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 23 May 2007 10:20:45 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705231420.l4NEKjW0027265@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From gbillios at gmail.com 2007-05-23 10:20 EST ------- rpm -q --whatprovides libperl.so perl-libs-5.8.8-18.fc7 nothing custom here -> 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 Wed May 23 18:11:02 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 23 May 2007 14:11:02 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705231811.l4NIB2Yg020096@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 hlein at inode.at changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hlein at inode.at ------- Additional Comments From hlein at inode.at 2007-05-23 14:10 EST ------- libperl.so is still missing in perl-5.8.8-18.fc7.i386.rpm (size 10.696.821) downloaded from http://fedora.inode.at/development/i386/os/Fedora/ Regards Helmut -- 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 May 23 18:13:28 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 23 May 2007 14:13:28 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705231813.l4NIDSE3020313@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From tcallawa at redhat.com 2007-05-23 14:13 EST ------- (In reply to comment #15) > libperl.so is still missing in perl-5.8.8-18.fc7.i386.rpm (size 10.696.821) > downloaded from http://fedora.inode.at/development/i386/os/Fedora/ That's good. Its not supposed to be in perl. Its in perl-libs now. ~spot -- 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 May 23 19:18:38 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 23 May 2007 15:18:38 -0400 Subject: [Bug 240540] perl-5.8.8-17.fc7 omits libperl.so In-Reply-To: Message-ID: <200705231918.l4NJIcqE027003@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-5.8.8-17.fc7 omits libperl.so https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240540 ------- Additional Comments From hlein at inode.at 2007-05-23 15:18 EST ------- Thanks. So, there is (was) a missing dependency (for yum) when updating from an earlier version. Regards Helmut -- 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 May 24 14:45:39 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 24 May 2007 10:45:39 -0400 Subject: [Bug 233879] man-pages: unowned directories In-Reply-To: Message-ID: <200705241445.l4OEjd91014851@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: man-pages: unowned directories https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233879 pknirsch at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|filesystem |perl AssignedTo|pknirsch at redhat.com |rnorwood at redhat.com QAContact| |dkl at redhat.com CC| |fedora-perl-devel- | |list at redhat.com ------- Additional Comments From pknirsch at redhat.com 2007-05-24 10:45 EST ------- Perl related manpage directories should be owned by the perl package. Reassigning. Read ya, Phil -- 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 May 24 16:31:29 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 24 May 2007 12:31:29 -0400 Subject: [Bug 241251] New: perl-SOAP-Lite does not install due to missing dependencies 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=241251 Summary: perl-SOAP-Lite does not install due to missing dependencies Product: Fedora EPEL Version: el5 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-SOAP-Lite AssignedTo: mmcgrath at redhat.com ReportedBy: dzrudy at gmail.com QAContact: extras-qa at fedoraproject.org CC: fedora-perl-devel-list at redhat.com Description of problem: The perl-SOAP-Lite package that Bugzilla 3.0 depends on (see bug#: 241206) fails to install due to missing dependencies. I have attached the output of yum install perl-SOAP-Lite ------- Additional Comments From dzrudy at gmail.com 2007-05-24 12:31 EST ------- Created an attachment (id=155361) --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=155361&action=view) Output of yum install perl-SOAP-Lite -- 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 May 24 16:36:31 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Thu, 24 May 2007 12:36:31 -0400 Subject: [Bug 241251] perl-SOAP-Lite does not install due to missing dependencies In-Reply-To: Message-ID: <200705241636.l4OGaVBs028272@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-SOAP-Lite does not install due to missing dependencies https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241251 dzrudy at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |241206 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 May 25 18:40:38 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Fri, 25 May 2007 14:40:38 -0400 Subject: [Bug 241251] perl-SOAP-Lite does not install due to missing dependencies In-Reply-To: Message-ID: <200705251840.l4PIecG5014766@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-SOAP-Lite does not install due to missing dependencies https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=241251 ianburrell at gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ianburrell at gmail.com ------- Additional Comments From ianburrell at gmail.com 2007-05-25 14:40 EST ------- It looks like perl-SOAP-Lite-0.68-4 has dependencies on perl(MQSeries). The most recent spec in CVS has requires filtering to remove that dependency (it is optional). Unfortunately, the spec has release 2.1 which is before than the previous release of 4 so the new spec is not being included in the repository or not being installed. -- 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 chicks at chicks.net Sun May 27 00:43:51 2007 From: chicks at chicks.net (Christopher Hicks) Date: Sat, 26 May 2007 20:43:51 -0400 Subject: Fedora to CPAN mapping... In-Reply-To: <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> Message-ID: <20070527004351.GG27084@chicks.net> On Tue, May 22, 2007 at 09:07:49PM -0700, Chris Weyl wrote: > Well, I don't know if we need a "shame page"... I've found asking for > updates to usually be as easy as filing a "update? pretty please?" > bug. Yes yes. > Do you see an area where we could improve as a whole in? I'm a totally happy customer! I've heard whining about the perl builds in Red Hat and Fedora, but I've been unscathed. The mod_perl updates were a pain once upon a time, but not in ages. > I'm going to poke around with seeing what statistics I can generate. Cool. -- "The problem with troubleshooting is that trouble shoots back!" From cweyl at alumni.drew.edu Mon May 28 18:25:20 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Mon, 28 May 2007 11:25:20 -0700 Subject: Fedora to CPAN mapping... In-Reply-To: <20070527004351.GG27084@chicks.net> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> Message-ID: <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> On 5/26/07, Christopher Hicks wrote: > On Tue, May 22, 2007 at 09:07:49PM -0700, Chris Weyl wrote: > > Do you see an area where we could improve as a whole in? > > I'm a totally happy customer! I've heard whining about the perl builds in Red Hat and Fedora, but I've been unscathed. The mod_perl updates were a pain once upon a time, but not in ages. Still, I'm always open to constructive suggestions. Neither anyone nor anything is perfect :) So... Still rather wimpy with the statistics, I'm afraid. All I really did was add a counter for the total # of packages (707!) at the top of the page, as well as a "last generated" bit. I've rigged it to run daily and push out to here until we find a more proper place to put it: http://home.comcast.net/~ckweyl/fedora_perl.html Again: * no non-CPAN module support yet (working on it) * works off of CVS, not packages in the repos * still definitely not a finished product Is there anything else that would be useful? I'm thinking of having it spit out either a page per owner listing all their packages, or another large page with an index at the top and individual tables per owner. (Though part of me is resisting this -- it's contrary to what I'd like to see happen, that is, people taking ownership of perl as a whole in Fedora.) -Chris -- Chris Weyl Ex astris, scientia From tcallawa at redhat.com Mon May 28 18:45:43 2007 From: tcallawa at redhat.com (Tom "spot" Callaway) Date: Mon, 28 May 2007 13:45:43 -0500 Subject: Fedora to CPAN mapping... In-Reply-To: <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> Message-ID: <1180377943.6254.415.camel@localhost.localdomain> On Mon, 2007-05-28 at 11:25 -0700, Chris Weyl wrote: > Is there anything else that would be useful? I'm thinking of having > it spit out either a page per owner listing all their packages, or > another large page with an index at the top and individual tables per > owner. (Though part of me is resisting this -- it's contrary to what > I'd like to see happen, that is, people taking ownership of perl as a > whole in Fedora.) Well, I would certainly like to be able to see the perl packages I maintain, separate from the main list. :) ~spot From bugzilla at redhat.com Tue May 29 11:48:41 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Tue, 29 May 2007 07:48:41 -0400 Subject: [Bug 241651] New: perl-DBI should be updated... 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=241651 Summary: perl-DBI should be updated... Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: medium Component: perl-DBI AssignedTo: rnorwood at redhat.com ReportedBy: oliver at linux-kernel.at CC: fedora-perl-devel-list at redhat.com http://search.cpan.org/~timb/DBI-1.56/ Currently only 1.53 is available. It doesn't only include various fixes, but also the new DBD::Gofer (introduced with 1.54). Yes, there are subtle changes to the DBI internals, that may affect current code, but perfect for -devel I would say. However, users of Perl >= 5.9.5 will need at least DBI 1.54 - I'm not sure what the plan in -devel is for Perl, but if we start trying out 5.9.4 (current perl developer version), we'll need updated DBI as well - sooner or later. Just my 2 cent. -- 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 cweyl at alumni.drew.edu Tue May 29 18:16:40 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Tue, 29 May 2007 11:16:40 -0700 Subject: Fedora to CPAN mapping... In-Reply-To: <1180377943.6254.415.camel@localhost.localdomain> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> <1180377943.6254.415.camel@localhost.localdomain> Message-ID: <7dd7ab490705291116y5399a468xa249afaa4c59ef77@mail.gmail.com> On 5/28/07, Tom spot Callaway wrote: > On Mon, 2007-05-28 at 11:25 -0700, Chris Weyl wrote: > > > Is there anything else that would be useful? I'm thinking of having > > it spit out either a page per owner listing all their packages, or > > another large page with an index at the top and individual tables per > > owner. (Though part of me is resisting this -- it's contrary to what > > I'd like to see happen, that is, people taking ownership of perl as a > > whole in Fedora.) > > Well, I would certainly like to be able to see the perl packages I > maintain, separate from the main list. :) Fine, fine, fine :) There's a _really_ rough list and simple breakout at: http://home.comcast.net/~ckweyl/fedora/ -Chris -- Chris Weyl Ex astris, scientia From kcorbin at theiqgroup.com Tue May 29 18:51:54 2007 From: kcorbin at theiqgroup.com (Kelly Corbin) Date: Tue, 29 May 2007 13:51:54 -0500 Subject: Perl splitting In-Reply-To: <83EC471D07F5CF385D285B42@[10.169.6.226]> References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@[10.169.6.226]> Message-ID: <465C764A.9050401@theiqgroup.com> Kenneth Porter wrote: > On Monday, May 14, 2007 7:35 AM +0200 Ralf Corsepius > wrote: > >> Yes, but ... how many _users_ do really need ExtUtils::MakeMaker or >> Test:: modules? Perl devs will, normal users won't except when other >> package will pull them in. > > >> Before the split, it was technically impossible to replace core perl >> modules, now we at least have the option to do so for those modules >> which have been split out. > > > In fact, EU:MM is exactly the module I needed to manually upgrade in the > past, and had to install a local (unpackaged) version in my build > environment to do so. I see this as a boon to dealing with broken > outdated core packages that can now be updated in isolation without the > extreme of updating the entire core. > > This doesn't affect Fedora so much, with its rapid pace of development, > but other, more conservative distros (eg. RHEL and CentOS) inherit > Fedora packages and will benefit from this compartmentalization of change. I wholeheartedly agree! I recently moved development of my application from RHEL to FC and was disappointed to have to package our own perl-Test-Simple because the Test::Builder in the main perl package was still broken. Everything else came as separate modules as needed. So, it looks like now with FC7 (and esp. with FC8), even if Test::Builder still gives me problems, I'm only *upgrading* a package; not overwriting files that exist in another core package. Very nice... Kelly -- -------------------------------------------- -- Kelly Corbin -- Network Administrator -- -- http://www.theiqgroup.com -- -- The IQ Group, Inc. -- 11460 S. Hunter Dr. -- Olathe, KS 66061 -- (913)-722-6700 x105 -- Fax 866-714-7282 -------------------------------------------- From rnorwood at redhat.com Tue May 29 19:44:44 2007 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 29 May 2007 15:44:44 -0400 Subject: Perl splitting In-Reply-To: <465C764A.9050401@theiqgroup.com> (Kelly Corbin's message of "Tue, 29 May 2007 13:51:54 -0500") References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@[10.169.6.226]> <465C764A.9050401@theiqgroup.com> Message-ID: Kelly Corbin writes: [...] > I wholeheartedly agree! I recently moved development of my > application from RHEL to FC and was disappointed to have to package > our own perl-Test-Simple because the Test::Builder in the main perl > package was still broken. Everything else came as separate modules as > needed. Hi, Broken how? Do you have a bugzilla? 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 May 30 04:40:30 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 30 May 2007 00:40:30 -0400 Subject: [Bug 239333] Branch perl-Net-Server for EPEL In-Reply-To: Message-ID: <200705300440.l4U4eU0w001141@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: Branch perl-Net-Server for EPEL https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=239333 kevin at tummy.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE ------- Additional Comments From kevin at tummy.com 2007-05-30 00:40 EST ------- Built on el-4, el-5... closing this bug now. -- 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 chicks at chicks.net Wed May 30 16:56:51 2007 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 30 May 2007 12:56:51 -0400 Subject: Fedora to CPAN mapping... In-Reply-To: <7dd7ab490705291116y5399a468xa249afaa4c59ef77@mail.gmail.com> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> <1180377943.6254.415.camel@localhost.localdomain> <7dd7ab490705291116y5399a468xa249afaa4c59ef77@mail.gmail.com> Message-ID: <20070530165651.GC23735@chicks.net> On Tue, May 29, 2007 at 11:16:40AM -0700, Chris Weyl wrote: > Fine, fine, fine :) There's a _really_ rough list and simple breakout at: > > http://home.comcast.net/~ckweyl/fedora/ If you released code we could send you patches. :-/ -- "The problem with troubleshooting is that trouble shoots back!" From bugzilla at redhat.com Wed May 30 18:12:56 2007 From: bugzilla at redhat.com (bugzilla at redhat.com) Date: Wed, 30 May 2007 14:12:56 -0400 Subject: [Bug 240918] perl-HTML-Encoding-0.53 is available In-Reply-To: Message-ID: <200705301812.l4UICu2D026031@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-HTML-Encoding-0.53 is available https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240918 ville.skytta at iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE Fixed In Version| |0.53-1 ------- Additional Comments From ville.skytta at iki.fi 2007-05-30 14:12 EST ------- Done for devel, F[67] updates probably coming later. -- 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 cweyl at alumni.drew.edu Wed May 30 19:51:54 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 30 May 2007 12:51:54 -0700 Subject: Fedora to CPAN mapping... In-Reply-To: <20070530165651.GC23735@chicks.net> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> <1180377943.6254.415.camel@localhost.localdomain> <7dd7ab490705291116y5399a468xa249afaa4c59ef77@mail.gmail.com> <20070530165651.GC23735@chicks.net> Message-ID: <7dd7ab490705301251t4087ad74p335e37a9b290c528@mail.gmail.com> On 5/30/07, Christopher Hicks wrote: > On Tue, May 29, 2007 at 11:16:40AM -0700, Chris Weyl wrote: > > Fine, fine, fine :) There's a _really_ rough list and simple breakout at: > > > > http://home.comcast.net/~ckweyl/fedora/ > > If you released code we could send you patches. :-/ :) I'm poking around, trying to see what it'd take to get this into either Fedora cvs, or maybe as some sort of a "hosted project". No aversions to releasing things as tarballs, but having it in a RCS somewhere would make collaboration / patches so much easier. -Chris -- Chris Weyl Ex astris, scientia From chicks at chicks.net Wed May 30 20:12:46 2007 From: chicks at chicks.net (Christopher Hicks) Date: Wed, 30 May 2007 16:12:46 -0400 Subject: Fedora to CPAN mapping... In-Reply-To: <7dd7ab490705301251t4087ad74p335e37a9b290c528@mail.gmail.com> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> <1180377943.6254.415.camel@localhost.localdomain> <7dd7ab490705291116y5399a468xa249afaa4c59ef77@mail.gmail.com> <20070530165651.GC23735@chicks.net> <7dd7ab490705301251t4087ad74p335e37a9b290c528@mail.gmail.com> Message-ID: <20070530201246.GD7250@chicks.net> On Wed, May 30, 2007 at 12:51:54PM -0700, Chris Weyl wrote: > On 5/30/07, Christopher Hicks wrote: > >On Tue, May 29, 2007 at 11:16:40AM -0700, Chris Weyl wrote: > >> Fine, fine, fine :) There's a _really_ rough list and simple breakout at: > >> > >> http://home.comcast.net/~ckweyl/fedora/ > > > >If you released code we could send you patches. :-/ > > :) I'm poking around, trying to see what it'd take to get this into > either Fedora cvs, or maybe as some sort of a "hosted project". No > aversions to releasing things as tarballs, but having it in a RCS > somewhere would make collaboration / patches so much easier. Sounds good. Thanks for what you've done so far. It is very slick and getting even better. I'm assuming you've noticed that some of the POE package versions are dorked and show as %(rpmver)? Another apparent issue is that we have no idea of what version of the module was current when a given version of fedora froze, but there may be enough module release history for some modules to figure that out. From here out we can just say "this is the version that was on CPAN on freeze day". I'll try to generate the data from backpan this weekend if nobody beats me to it. ;) Thanks again all around. -- "The problem with troubleshooting is that trouble shoots back!" From cweyl at alumni.drew.edu Thu May 31 04:56:30 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Wed, 30 May 2007 21:56:30 -0700 Subject: Fedora to CPAN mapping... In-Reply-To: <20070530201246.GD7250@chicks.net> References: <7dd7ab490705212132r4dd406c2h398486764b351a99@mail.gmail.com> <20070522122408.GB2588@chicks.net> <7dd7ab490705222107i654b8915x56cee1e06b782c2c@mail.gmail.com> <20070527004351.GG27084@chicks.net> <7dd7ab490705281125p44dbbbccge4b1ab890eefde8c@mail.gmail.com> <1180377943.6254.415.camel@localhost.localdomain> <7dd7ab490705291116y5399a468xa249afaa4c59ef77@mail.gmail.com> <20070530165651.GC23735@chicks.net> <7dd7ab490705301251t4087ad74p335e37a9b290c528@mail.gmail.com> <20070530201246.GD7250@chicks.net> Message-ID: <7dd7ab490705302156u764602bfy53c5d9ef1d8b2d37@mail.gmail.com> On 5/30/07, Christopher Hicks wrote: > On Wed, May 30, 2007 at 12:51:54PM -0700, Chris Weyl wrote: > > :) I'm poking around, trying to see what it'd take to get this into > > either Fedora cvs, or maybe as some sort of a "hosted project". No > > aversions to releasing things as tarballs, but having it in a RCS > > somewhere would make collaboration / patches so much easier. > > Sounds good. Thanks for what you've done so far. It is very slick and getting even better. Thanks! I just found http://fedoraproject.org/wiki/Infrastructure/ProjectHosting; hopefully someone on fedora-devel-list will be able to tell me how to actually invoke the new project process :) > I'm assuming you've noticed that some of the POE package versions are dorked and show as %(rpmver)? Yeah, um, that's me. The mapping script doesn't actually evaluate %{version} against the spec file, it simply looks for (V|v)ersion:. POE modules had this tendency to go from, say, 0.95, 0.96, 0.9601, 0.97... That was my classy way of avoiding epoch's. I'm working to reset that; it helps the bingos has largely switched to a more consistent versioning scheme. > Another apparent issue is that we have no idea of what version of the module was current when a given version of fedora froze, but there may be enough module release history for some modules to figure that out. From here out we can just say "this is the version that was on CPAN on freeze day". I'll try to generate the data from backpan this weekend if nobody beats me to it. ;) Now that would be interesting for some modules -- what version a given Fedora release started out at vs where it is currently (or ended up at). I'm also thinking a "devel not current against CPAN" list/alert would be nice. > Thanks again all around. No problem. I'm holding you to your patches comment :) -Chris -- Chris Weyl Ex astris, scientia From kcorbin at theiqgroup.com Thu May 31 17:26:31 2007 From: kcorbin at theiqgroup.com (Kelly Corbin) Date: Thu, 31 May 2007 12:26:31 -0500 Subject: Perl splitting In-Reply-To: References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@[10.169.6.226]> <465C764A.9050401@theiqgroup.com> Message-ID: <465F0547.6000307@theiqgroup.com> I'm the sysadmin, not the developer so I don't have all the details at the moment (I'm waiting to hear back from him), but here's his quote to me: "perl-5.8.8 has an outdated Test::Builder that's accidentally allowing an error to propagate outside of its code -- this is triggering the __DIE__ handler" An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with cpan2rpm solved the issue for us, but of course had to be installed with --replacefiles. I'll post as soon as I know more. Kelly Robin Norwood wrote: > Kelly Corbin writes: > > [...] > > >>I wholeheartedly agree! I recently moved development of my >>application from RHEL to FC and was disappointed to have to package >>our own perl-Test-Simple because the Test::Builder in the main perl >>package was still broken. Everything else came as separate modules as >>needed. > > > Hi, > > Broken how? Do you have a bugzilla? > > Thanks, > > -RN > -- -------------------------------------------- -- Kelly Corbin -- Network Administrator -- -- http://www.theiqgroup.com -- -- The IQ Group, Inc. -- 11460 S. Hunter Dr. -- Olathe, KS 66061 -- (913)-722-6700 x105 -- Fax 866-714-7282 -------------------------------------------- From cweyl at alumni.drew.edu Thu May 31 17:54:28 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 31 May 2007 10:54:28 -0700 Subject: Perl splitting In-Reply-To: <465F0547.6000307@theiqgroup.com> References: <46422A9B.3090205@di.uminho.pt> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@10.169.6.226> <465C764A.9050401@theiqgroup.com> <465F0547.6000307@theiqgroup.com> Message-ID: <7dd7ab490705311054t5a7fe4ccja199522e0fa40833@mail.gmail.com> On 5/31/07, Kelly Corbin wrote: > I'm the sysadmin, not the developer so I don't have all the details at > the moment (I'm waiting to hear back from him), but here's his quote to me: > "perl-5.8.8 has an outdated Test::Builder that's accidentally allowing > an error to propagate outside of its code -- this is triggering the > __DIE__ handler" > > An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with > cpan2rpm solved the issue for us, but of course had to be installed with > --replacefiles. > > I'll post as soon as I know more. Hmm... What's the @INC directory scan order in our perl? I was under the impression it went site, vendor, core; that way you should be able to override something in core by installing it in either of the other two places (so perl finds it first). ...or am I missing something here? Disambiguation invited :) -Chris -- Chris Weyl Ex astris, scientia From altblue at n0i.net Thu May 31 18:48:40 2007 From: altblue at n0i.net (Marius Feraru) Date: Thu, 31 May 2007 21:48:40 +0300 Subject: Perl splitting In-Reply-To: <7dd7ab490705311054t5a7fe4ccja199522e0fa40833@mail.gmail.com> References: <46422A9B.3090205@di.uminho.pt> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@10.169.6.226> <465C764A.9050401@theiqgroup.com> <465F0547.6000307@theiqgroup.com> <7dd7ab490705311054t5a7fe4ccja199522e0fa40833@mail.gmail.com> Message-ID: <465F1888.3010001@n0i.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Weyl wrote: > On 5/31/07, Kelly Corbin wrote: >> An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with >> cpan2rpm solved the issue for us, but of course had to be installed with >> --replacefiles. > Hmm... What's the @INC directory scan order in our perl? Doesn't matter, Fedora uses a single directory structure for all manual pages (%_mandir), same goes for scripts (%_bindir). So, even if those modules will be "vendor-installed", man pages & scripts will clobber files provided by "core" perl distro. - -- Marius Feraru -----BEGIN PGP SIGNATURE----- iD8DBQFGXxiHtZHp/AYZiNkRAtwwAJsFE3hWUoih+Un1s7cJsdhU7KyeqwCghZb4 kyixX9fv+dd0E2BmgsZoQ/U= =PaPD -----END PGP SIGNATURE----- From cweyl at alumni.drew.edu Thu May 31 20:26:34 2007 From: cweyl at alumni.drew.edu (Chris Weyl) Date: Thu, 31 May 2007 13:26:34 -0700 Subject: Perl splitting In-Reply-To: <465F1888.3010001@n0i.net> References: <46422A9B.3090205@di.uminho.pt> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@10.169.6.226> <465C764A.9050401@theiqgroup.com> <465F0547.6000307@theiqgroup.com> <7dd7ab490705311054t5a7fe4ccja199522e0fa40833@mail.gmail.com> <465F1888.3010001@n0i.net> Message-ID: <7dd7ab490705311326g148c8f80kb026aeb7308d1417@mail.gmail.com> On 5/31/07, Marius Feraru wrote: > Chris Weyl wrote: > > On 5/31/07, Kelly Corbin wrote: > >> An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with > >> cpan2rpm solved the issue for us, but of course had to be installed with > >> --replacefiles. > > Hmm... What's the @INC directory scan order in our perl? > Doesn't matter, Fedora uses a single directory structure for all manual > pages (%_mandir), same goes for scripts (%_bindir). > > So, even if those modules will be "vendor-installed", man pages & scripts > will clobber files provided by "core" perl distro. Heh. Yes, those definitely would. I suppose it'd be easy enough to put the conflicting files in %doc, if they weren't needed as part of the update... Clearly not optimal, but an OK workaround for a local system. -Chris -- Chris Weyl Ex astris, scientia From kcorbin at theiqgroup.com Thu May 31 21:02:09 2007 From: kcorbin at theiqgroup.com (Kelly Corbin) Date: Thu, 31 May 2007 16:02:09 -0500 Subject: Perl splitting In-Reply-To: <465F0547.6000307@theiqgroup.com> References: <46422A9B.3090205@di.uminho.pt> <1178772335.7713.11.camel@mccallu m.corsepiu.local> <46474D81.7080807@di.uminho.pt> <1179120916.4735.274.camel@mccallum.corsepiu.local> <83EC471D07F5CF385D285B42@[10.169.6.226]> <465C764A.9050401@theiqgroup.com> <465F0547.6000307@theiqgroup.com> Message-ID: <465F37D1.2090205@theiqgroup.com> Here was the exact problem we ran into: "It throws "Can't call method 'isa' on an unblessed reference" inside of _is_object. Of course, Test::* is not supposed to let fatals leak out of its internal code. This was addressed in the version immediately following." This bug must be fixed in 0.68 apparently (from the change log): 0.68 Tue Mar 13 17:27:26 PDT 2007 Bug fixes * If your code has a $SIG{__DIE__} handler in some cases functions like use_ok(), require_ok(), can_ok() and isa_ok() could trigger that handler. [rt.cpan.org 23509] but a bug introduced 0.68 was fixed in 0.70 making it the optimal version. Thanks! Kelly Kelly Corbin wrote: > I'm the sysadmin, not the developer so I don't have all the details at > the moment (I'm waiting to hear back from him), but here's his quote to me: > "perl-5.8.8 has an outdated Test::Builder that's accidentally allowing > an error to propagate outside of its code -- this is triggering the > __DIE__ handler" > > An updated perl-Test-Simple-0.70-1.noarch.rpm package we made with > cpan2rpm solved the issue for us, but of course had to be installed with > --replacefiles. > > I'll post as soon as I know more. > > Kelly > > Robin Norwood wrote: > >> Kelly Corbin writes: >> >> [...] >> >> >>> I wholeheartedly agree! I recently moved development of my >>> application from RHEL to FC and was disappointed to have to package >>> our own perl-Test-Simple because the Test::Builder in the main perl >>> package was still broken. Everything else came as separate modules as >>> needed. >> >> >> >> Hi, >> >> Broken how? Do you have a bugzilla? >> >> Thanks, >> >> -RN >> > -- -------------------------------------------- -- Kelly Corbin -- Network Administrator -- -- http://www.theiqgroup.com -- -- The IQ Group, Inc. -- 11460 S. Hunter Dr. -- Olathe, KS 66061 -- (913)-722-6700 x105 -- Fax 866-714-7282 --------------------------------------------