perl-devel May 2006

perl-devel@lists.fedoraproject.org

6 participants
46 discussions

[Bug 191653] New: RFE: DBD::MySQL has been updated to 3.0003
by Red Hat Bugzilla 17 Jul '06

17 Jul '06

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=191653 Summary: RFE: DBD::MySQL has been updated to 3.0003 Product: Fedora Core Version: devel Platform: All URL: http://search.cpan.org/src/CAPTTOFU/DBD-mysql- 3.0003/ChangeLog OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: perl-DBD-MySQL AssignedTo: jvdias(a)redhat.com ReportedBy: rmo(a)sunnmore.net CC: fedora-perl-devel-list(a)redhat.com Description of problem: DBD::Mysql has been updated Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 4

[Bug 184319] New: Spamassassin and SELinux
by Red Hat Bugzilla 28 Jun '06

28 Jun '06

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=184319 Summary: Spamassassin and SELinux Product: Fedora Core Version: fc4 Platform: i386 OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: rsandu(a)softhome.net 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: As described in SpamAssassin's man page, the program must create user_prefs in $HOME/.spamassassin, where $HOME is the homedirectory of the user spamassassin is run under. When spamc is invoked from Postfix's master.cf file (as described at http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix) and SELinux is enabled, Spamassassin can't create user_prefs file in /home/someuser, even if "someuser" was created on purpose. Version-Release number of selected component (if applicable): spamassassin-3.0.4-2.fc4 selinux-policy-targeted-1.27.1-2.22 postfix-2.2.2-2 (stock Fedora Core 4 + updates March 06, 2006) How reproducible: Always. Steps to Reproduce: 1. Invoke Spamassassin as a filter, from Postfix, as described in http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix, with SELinux enabled. Postfix users should be virtual users. Actual results: The process can't write user_prefs under /home/someuser. Expected results: A predefined system user should be created when installing Spamassassin (by the rpm), with an appropiate, FHS-compliant homedirectory, in order to provide a place to create user_prefs, when Postfix users are virtual users and SELinux is enabled. Spamassassin docs should indicate the correct way to proceed/configure in such cases. Additional info: -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.

1 2

[Bug 169236] New: New version of SpamAssassin available (3.1.0)
by Red Hat Bugzilla 07 Jun '06

07 Jun '06

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=169236 Summary: New version of SpamAssassin available (3.1.0) Product: Fedora Core Version: fc4 Platform: All URL: http://svn.apache.org/repos/asf/spamassassin/branches/3. 1/UPGRADE OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: milan.kerslager(a)pslib.cz CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@redhat.com New SpamAssassin 3.1.0 introduces a lot of changes (mostly move to plugins). Will be there a new fersion for FC4 or 3.1.x is supposed to be in FC5 only? Are there some issues for FC4? -- 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 11

[Bug 178580] New: /etc/sysconfig/spamassasin is always modified
by Red Hat Bugzilla 06 Jun '06

06 Jun '06

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=178580 Summary: /etc/sysconfig/spamassasin is always modified Product: Fedora Core Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: spamassassin AssignedTo: wtogami(a)redhat.com ReportedBy: wtogami(a)redhat.com CC: fedora-perl-devel- list@redhat.com,felicity@kluge.net,jm@jmason.org,parkerm @pobox.com,reg+redhat@sidney.com,wtogami@redhat.com QA discovered that /etc/sysconfig/spamassasin is being replaced during every package intallation or upgrade. # -a and --auto-whitelist options were removed from 3.0.0 # prevent service startup failure perl -p -i -e 's/(["\s]-\w+)a/$1/ ; s/(["\s]-)a(\w+)/$1$2/ ; s/(["\s])-a\b/$1/' /etc/sysconfig/spamassassin perl -p -i -e 's/ --auto-whitelist//' /etc/sysconfig/spamassassin Since FC3 spamassassin.spec %post contained this to remove user added options during an upgrade from pre-3.0 SA that caused the new version to fail. QA discovered that this perl syntax actually creates another file and deletes the original file. This means that even if no change happens, the file has a different timestamp and selinux security context. Impact: Not much, but it should be fixed some time in the future. Fix: This probably involves testing before doing the modification in order to avoid an unnecessary replacement. In the replacement case chcon is needed in order to maintain the correct selinux context. -- 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 5

Fwd: libxml1 going away
by Chris Weyl 29 May '06

29 May '06

FYI... ---------- Forwarded message ---------- From: Bill Nottingham <notting(a)redhat.com> Date: May 29, 2006 1:19 PM Subject: Re: libxml1 going away To: List for Fedora Package Maintainers <fedora-maintainers(a)redhat.com> Jesse Keating (jkeating(a)redhat.com) said: > libxml1 has reached its end of days. > > Gtk-Perl > R-gnomeGUI > > Both have listed deps on libxml1. Can these be moved to libxml2? We're > really really really rather not bring libxml1 into Extras. I would like > to have libxml1 removed from the distribution by Test 1. The way to fix this is to port those to GTK+2/GNOME 2, not just from libxml1 to libxml2. Bill -- Fedora-maintainers mailing list Fedora-maintainers(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Chris Weyl Ex astris, scientia

1 0

[Bug 175459] wrong coding
by Red Hat Bugzilla 29 May '06

29 May '06

Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: wrong coding https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175459 mmaslano(a)redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Pointless warning message |wrong coding Version|fc4 |fc5 Status|REOPENED |ASSIGNED Component|groff |perl AssignedTo|mmaslano(a)redhat.com |jvdias(a)redhat.com QAContact|mikem(a)redhat.com |dkl(a)redhat.com CC| |fedora-perl-devel- | |list(a)redhat.com ------- Additional Comments From mmaslano(a)redhat.com 2006-05-29 08:43 EST ------- Manual page for perlcn isn't in UTF-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.

1 0

Upstream changing Licenses [Was: perl-Locale-Maketext-Simple.spec]
by Ralf Corsepius 27 May '06

27 May '06

On Wed, 2006-05-24 at 17:49 -0700, Steven Pritchard wrote: > Author: steve > > Update of /cvs/extras/rpms/perl-Locale-Maketext-Simple/FC-4 > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv6828 > > Modified Files: > .cvsignore perl-Locale-Maketext-Simple.spec sources > Log Message: > Update to 0.16. > License has changed to MIT. Steve, do you think upstream is legitimated to do so? I am facing the same situation with perl-Locale-Maketext-Lexicon (from the same author). There, upstream has changed the license from GPL/Artistic to MIT. IMO, by having done so, upstream probably has violated the law, because, in general, they cannot change the license a package unless they own the copyright of all parts a package consists of. Locale::Maketext::Simple only lists one author, with Locale::Maketext::Lexicon, the situation seems unclear: http://search.cpan.org/src/AUTRIJUS/Locale-Maketext-Lexicon-0.61/AUTHORS lists 20-25 contributors, while the source code only lists one individual (the CPAN maintainer). I am not certain on how to handle the situation. To be on the safe side, I considering to regard my perl-Locale-Maketext-Lexicon rpm as derivative work of the original work and consider to ship it under the GPL only. The fundamental questions would be: * Who owns contributions to code in CPAN having been released under GPL/Artistic before? IMO: If the "contribution is copyrightable", the contributor. He is contributing under the licenses the original author had granted. The original author is not legitimated to change the license on such contributions without explicit permission. * Is the maintainer of CPAN modules legitimated to change a license from GPL/Artistic to MIT? Here, I am not sure about the implications of the Artistic license. Opinions? What to do? Ralf

1 0

The next time you need to build a stack of modules...
by Steven Pritchard 18 May '06

18 May '06

There is a new option in cpanspec 1.66 (which should land in Extras soon), --follow. The next time you need to build a package for a module, you might want to try something like this: cpanspec -v --follow Some::Module When you specify --follow, cpanspec checks every BuildRequires that can be automatically determined from the module to see if it is available on the system ("rpm -q --whatprovides perl($module)") or in the configured repositories ("repoquery --whatprovides perl($module)"). If not, it adds it to the list of modules to process. I just tried this with OpenFrame (something I manually built all the dependencies for a while back), and it looks like I'm down to 5 required modules that aren't in Extras already. Steve -- Steven Pritchard - K&S Pritchard Enterprises, Inc. Email: steve(a)kspei.com http://www.kspei.com/ Phone: (618)398-3000 Mobile: (618)567-7320

2 1

Extras QA?
by Chris Weyl 16 May '06

16 May '06

Question -- I've been noticing that in extra's owners.list, a number of packages have this list's address as one of the QA emails. Should I be setting this on perl packages I own in extras? If so, is this something that ought to go in the Packaging/Perl wiki page? -Chris -- Chris Weyl Ex astris, scientia

1 0

[Bug 191350] Review Request: perl-Spreadsheet-ParseExcel
by Red Hat Bugzilla 15 May '06

15 May '06

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-Spreadsheet-ParseExcel https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=191350 ------- Additional Comments From mpeters(a)mac.com 2006-05-15 02:48 EST ------- New spec file and src.rpm: http://mpeters.us/fc_extras/perl-Spreadsheet-ParseExcel-0.2603-1.src.rpm http://mpeters.us/fc_extras/perl-Spreadsheet-ParseExcel.spec Ready for review. I went ahead and made the package arch dependent so that it can install and own the map file. The japanese support that the map file provides will not work until bug #191387 is resolved, but when bug #191387 is resolved it should *just work* (famous last words ...) NOTES - The package is arch dependent solely because of the map file. This causes a completely empty and useless debuginfo package. So I set a macro in the spec file to not build the debuginfo package. The license is issue is resolved (GPL or perl). -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

perl-devel May 2006