[Bug 241651] New: perl-DBI should be updated...
by Red Hat Bugzilla
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(a)redhat.com
ReportedBy: oliver(a)linux-kernel.at
CC: fedora-perl-devel-list(a)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.
16 years, 11 months
Fedora to CPAN mapping...
by Chris Weyl
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
16 years, 11 months
Perl splitting
by Jose Pedro Oliveira
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/ *
16 years, 11 months
[Bug 240918] New: perl-HTML-Encoding-0.53 is available
by Red Hat Bugzilla
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(a)iki.fi
ReportedBy: fevapp(a)o2.pl
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)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.
16 years, 11 months
[Bug 233879] man-pages: unowned directories
by Red Hat Bugzilla
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.
16 years, 12 months
[Bug 240402] New: SpamAssassin sa-update gpg verification failure
by Red Hat Bugzilla
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(a)jmason.org,parkerm
@pobox.com,reg+redhat@sidney.com,wtogami(a)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.
16 years, 12 months
Re: Thoughts...
by Robin Norwood
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
17 years
Template-XML
by Oliver Ruebenacker
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/
17 years
Thoughts...
by Chris Weyl
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
17 years
