perl-devel May 2007

perl-devel@lists.fedoraproject.org

14 participants
80 discussions

Start a nNew thread

[Bug 241651] New: perl-DBI should be updated...
by Red Hat Bugzilla 08 Jun '07

08 Jun '07

1 2

[Bug 241251] New: perl-SOAP-Lite does not install due to missing dependencies
by Red Hat Bugzilla 06 Jun '07

06 Jun '07

1 3

Fedora to CPAN mapping...
by Chris Weyl 04 Jun '07

04 Jun '07

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

3 11

Perl splitting
by Jose Pedro Oliveira 31 May '07

31 May '07

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@di.uminho.pt * http://gsd.di.uminho.pt/members/jpo/ *

7 19

[Bug 240918] New: perl-HTML-Encoding-0.53 is available
by Red Hat Bugzilla 30 May '07

30 May '07

1 1

[Bug 233879] man-pages: unowned directories
by Red Hat Bugzilla 24 May '07

24 May '07

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(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Component|filesystem |perl AssignedTo|pknirsch(a)redhat.com |rnorwood(a)redhat.com QAContact| |dkl(a)redhat.com CC| |fedora-perl-devel- | |list(a)redhat.com ------- Additional Comments From pknirsch(a)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.

1 0

[Bug 240402] New: SpamAssassin sa-update gpg verification failure
by Red Hat Bugzilla 23 May '07

23 May '07

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(a)redhat.com ReportedBy: amessina(a)messinet.com CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@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 <root> 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.

1 1

Re: Thoughts...
by Robin Norwood 22 May '07

22 May '07

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 <rc040203 freenet de> writes: >On Sat, 2007-05-19 at 16:04 -0400, Robin Norwood wrote: >> Ralf Corsepius <rc040203 freenet de> 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

2 1

Template-XML
by Oliver Ruebenacker 21 May '07

21 May '07

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/

3 4

Thoughts...
by Chris Weyl 20 May '07

20 May '07

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? <grin>) 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

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel May 2007