Re: [rpms/perl-Plack] PR #1: Move Apache handler ro sub-packages
On 5/11/21 2:06 AM, Emmanuel Seyman wrote: eseyman commented on the pull-request: `Move Apache handler ro sub-packages` that you are following: `` Thank you for this PR, Jikta. I've been meaning to work on this since the next version of Bugzilla will require PSGI and having handlers in their own subpackages makes things simpler. Actually, I am surprized and irritated about not having been informed beforehand nor having been CC:-ed by any means. @Jitka: What is going on here? I can't deny thinking, Fedoras infrastructure has derailed into an unusable, bureaucratic mess. Ralf, any input before I merge this? No idea. Firstly I'd have to have look into this. Unfortunately, I probably will not have any time available for Fedora throughout the next couple of weeks.. Ralf ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: perl: warning: Setting locale failed.
On 1/8/19 6:51 PM, Tim Landscheidt wrote:
Petr Šabata wrote:
Adding
BuildRequires: glibc-all-langpacks
to all the *.specs obviously fixes this issue. However, I doubt this is
right, because I think these warnings originate from some rpm-internal
scripts and not from the packages.
I suspect you're running into the glibc-langpacks-all feature:
*
https://fedoraproject.org/wiki/Changes/Remove_glibc-langpacks-all_from_buildroot
*
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/VRIO4YQV2B2G2DUUYNRTVYQDFCMZSZGX/#B5SEICGIAETNXPRIE6VZT2VDKXRLJWSP
The locale shouldn't be set to en_US.utf8 is glibc-langpack-en is
not present. Where does it come from?
Judging from $LANG=de_DE.UTF-8 in my mock, it gets copied
from the "host" environment. And indeed,
mock/py/mockbuild/util.py has two instances of:
You seem to be right on the spot.
IMHO, mock should not propagate any "host" environment variables into
its chroots. It should be using a fixed set of predefined settings, instead.
| env['LANG'] = os.environ.setdefault('LANG', 'C.UTF-8')
Adding:
| config_opts['environment']['LANG'] = 'C'
I guess, this should be 'C.UTF-8' instead of 'C'
to ~/.config/mock.cfg seems to solve that.
Unfortunately, this doesn't help with koji-builds:
c.f. e.g.
https://kojipkgs.fedoraproject.org//work/tasks/7946/31907946/build.log
Apparently, something sets LANG="en_US.UTF-8" in koji and mock bogusly
propagates this into its chroots (Likely the servers are configured to
use LANG='en_US.UTF-8')
Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
perl: warning: Setting locale failed.
Hi,
ATM, many (all?) of my perl packages raise several warnings of the kind
below, when building them in mock:
...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
...
Adding
BuildRequires: glibc-all-langpacks
to all the *.specs obviously fixes this issue. However, I doubt this is
right, because I think these warnings originate from some rpm-internal
scripts and not from the packages.
So, what is the official fix to this issue/build-system regression?
Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: rawhide: Can't locate ExtUtils/CBuilder.pm
On 03/01/2018 11:33 AM, Paul Howarth wrote: On Thu, 1 Mar 2018 11:17:18 +0100 Petr Pisar wrote: On Thu, Mar 01, 2018 at 09:38:08AM +0100, Ralf Corsepius wrote: Hi, perl-Plack fails to build in rawhide with this error[1] Sorry, of course this was perl-Server-Starter, not perl-Plack. ... + /usr/bin/perl Build.PL --installdirs=vendor Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install the ExtUtils::CBuilder module) (@INC contains: /builddir/build/BUILD/Server-Starter-0.34/_build/lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295. ... f26, f27 and f28 build fine. What is going on here? perl-Plack does not carry any direct dependency on ExtUtils::CBuilder, so my guess would be a dependency is missing somewhere else. <https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/MWK6MLOWOIJ2UVMRILR3FAZZRE3X6OCM/> is happennning due to GCC removal from F29 build root. If you have a package with XS modules and use Module::Build, you need to build-require ExtUtils::CBuilder. In case of Server-Starter, there seems to be a bug in Module::Build::Base. It invokes auto_require() that for some reason has $self->c_source set to [], and thus it decides it needs a compiler and hence ExtUtils::CBuilder. I think this condition in auto_require() should be corrected: $self->needs_compiler( keys %$xs_files || defined $self->c_source ); and also the reason why $self->c_source is [] instead of undef should be investigated. That'll be because Server-Starter's Build.PL has "c_source => [qw()]," And that's generated by Minilla, so all non-XS Minilla-based dists are likely to be affected. I am not familiar with Minilla, but you seem to have a point. At least, removing this line from Build.PL lets building perl-Server-Starter succeed for rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=25390138 Ralf ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
rawhide: Can't locate ExtUtils/CBuilder.pm
Hi, perl-Plack fails to build in rawhide with this error[1] ... + /usr/bin/perl Build.PL --installdirs=vendor Can't locate ExtUtils/CBuilder.pm in @INC (you may need to install the ExtUtils::CBuilder module) (@INC contains: /builddir/build/BUILD/Server-Starter-0.34/_build/lib /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 5295. ... f26, f27 and f28 build fine. What is going on here? perl-Plack does not carry any direct dependency on ExtUtils::CBuilder, so my guess would be a dependency is missing somewhere else. Ralf [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1052034 https://kojipkgs.fedoraproject.org//work/tasks/4038/25384038/build.log ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Fedora-Live-26 fails to boot: A start job is running for dev-map...\x2drv.device
Sorry, wrong list. Ralf ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora-Live-26 fails to boot: A start job is running for dev-map...\x2drv.device
Hi, I have been trying to test Fedora-Workstation-Live-i386-26-*.n.0.iso Unfortunately, all attempts in recent weeks hang with this boot message: ... [...] A start job is running for dev-map...\x2drv.device Q: Which component is issuing this message? I just filed a BZ against device-mapper, but to my big surprise this package appears orphaned[1]. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1436096 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Intend to retire perl-Log-Any-Adapter-Dispatch
Hi, I intend to retire perl-Log-Any-Adapter-Dispatch for Fedora > 25. - This package currently FTBFSs in fc26, - This packages doesn't seem to be used by any other package in Fedora. - Its upstream appears "semi-dead" (Last update from 2013). If you still need this package, feel free to take over, otherwise I will retire it for Fedora >= 25, pretty soon. Ralf ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: spot pushed to perl-Log-Dispatch (master). "update to 2.60, disable test suite until Devel::Confess shows up in Fedora"
On 02/13/2017 03:59 PM, notificati...@fedoraproject.org wrote:
From 0e2119bee24ba67cb856f7a95d81a2944c69ab42 Mon Sep 17 00:00:00 2001
From: Tom Callaway
Date: Mon, 13 Feb 2017 09:59:11 -0500
Subject: update to 2.60, disable test suite until Devel::Confess shows up in
Fedora
@@ -49,6 +49,9 @@ BuildRequires: perl(Test::More) >= 0.96
BuildRequires: perl(Test::Fatal)
# N/A in Fedora < 24
BuildRequires: perl(Test::Needs)
+# Introduced in 2.60
+# Not in Fedora as of 2017-02-13
+# BuildRequires: perl(Devel::Confess)
# If LOG_DISPATCH_TEST_EMAIL is passed to tests, a sendmail will be needed,
# bug #1083418
@@ -97,7 +100,9 @@ make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
%{_fixperms} $RPM_BUILD_ROOT/*
%check
+%if 0
make test %{?with_release_tests:RELEASE_TESTING=1}
LOG_DISPATCH_TEST_EMAIL="root@localhost.localdomain"
+%endif
%files
%doc Changes
@@ -106,6 +111,10 @@ make test %{?with_release_tests:RELEASE_TESTING=1}
LOG_DISPATCH_TEST_EMAIL="root
%{_mandir}/man3/*.3pm*
%changelog
+* Mon Feb 13 2017 Tom Callaway - 2.60-1
+- update to 2.60
+- disabling tests until Devel::Confess shows up
+
* Sat Feb 11 2017 Fedora Release Engineering -
2.58-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild
Spot, you've outsmarted yourself.
Devel::Confess is not a testsuite requirement, it is a mandatory
runtime-requirement, without which this package at least partially
dysfunctional.
c.f.
Log-Dispatch-2.60/lib/Log/Dispatch.pm:use Devel::Confess;
Log-Dispatch-2.60/lib/Log/Dispatch/Conflicts.pm:Devel::Confess
Ralf
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Re: Removing perl from build root
On 04/04/2016 09:46 AM, Petr Pisar wrote: On Fri, Apr 01, 2016 at 05:00:14PM +0200, Ralf Corsepius wrote: On 04/01/2016 03:46 PM, Petr Pisar wrote: On Fri, Apr 01, 2016 at 12:14:43PM +0200, Petr Pisar wrote: On Thu, Mar 31, 2016 at 02:43:41PM +0100, Paul Howarth wrote: Requires: (perl-generators if perl-libs) That's interesting idea. I only worry there could be cases when the perl-generators were unnecessarily installed. E.g. you install vim-enhanced, thus you have perl-libs, and you install rpm-build for building non-perl packages. Then you will have perl-generators. I'm not sure how much it would bother people. One more issue. It would not work if you had a spec file that does not need a perl for building. Spec that only installs a perl script into /usr/bin. I know there are some. These package should be considered broken. We require run-time deps to be present as build-deps to make sure these packages actually are runable and installable. Oh, really? Yes. I know it's good to run tests, but still there are plenty of packages without tests (covering the perl scipts), so besides knowing we had all run-time dependencies on build-time, build-requiring them does not have other benefits. I wasn't referring to tests in particular. I was talking about run-time deps, which are required for proper run-time operation, which are not used at build time and therefore not explicitly BuildRequired. Classical example would be a package which installs a perl-script which is using some arbitrary perl modules to /usr/bin, but doesn't carry explicit checks for this scripts' requirements nor does a testsuite to exercise this scripts. Such kind of run-time package's deps silently (and often unnoticed) get added additional deps, which either add deps to nonexisting packages or break if a package is removed from Fedora. We've had quite a few such cases in Fedora's history. Most common case is perl packages, which after an package update require further perl-modules. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org
Re: Removing perl from build root
On 04/01/2016 03:46 PM, Petr Pisar wrote: On Fri, Apr 01, 2016 at 12:14:43PM +0200, Petr Pisar wrote: On Thu, Mar 31, 2016 at 02:43:41PM +0100, Paul Howarth wrote: Requires: (perl-generators if perl-libs) That's interesting idea. I only worry there could be cases when the perl-generators were unnecessarily installed. E.g. you install vim-enhanced, thus you have perl-libs, and you install rpm-build for building non-perl packages. Then you will have perl-generators. I'm not sure how much it would bother people. One more issue. It would not work if you had a spec file that does not need a perl for building. Spec that only installs a perl script into /usr/bin. I know there are some. These package should be considered broken. We require run-time deps to be present as build-deps to make sure these packages actually are runable and installable. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org
Re: Removing perl from build root
On 04/01/2016 03:33 PM, Paul Howarth wrote: I think people doing development work like that are less bothered about pulling in a few deps than the cloud/embedded people, where every megabyte is worth saving. Sizes matter at run-time, but I fail to understand why they would matter much at build-time. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/perl-devel@lists.fedoraproject.org
Re: jehane pushed to fusioninventory-agent (f23). "new version (..more)"
On 10/15/2015 07:46 PM, notificati...@fedoraproject.org wrote:
From c7493300b75beeed3980723ecddc68185438a0a8 Mon Sep 17 00:00:00 2001
From: jehane
Date: Sun, 11 Oct 2015 17:01:09 +0200
Subject: new version
- Upstream switch to github, minor spec adaptation
---
.gitignore | 1 +
fusioninventory-agent.spec | 16 ++--
sources| 2 +-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/.gitignore b/.gitignore
index c55cab8..5bdc389 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/FusionInventory-Agent-2.3.15.tar.gz
/FusionInventory-Agent-2.3.16.tar.gz
+/2.3.17.tar.gz
diff --git a/fusioninventory-agent.spec b/fusioninventory-agent.spec
index 75572f2..a8de963 100644
--- a/fusioninventory-agent.spec
+++ b/fusioninventory-agent.spec
@@ -9,11 +9,11 @@ Group: Applications/System
License: GPLv2+
URL: http://fusioninventory.org/
-Version: 2.3.16
-Release: 5%{?dist}
+Version: 2.3.17
+Release: 1%{?dist}
#BuildArch: noarch
-Source0:
http://search.cpan.org/CPAN/authors/id/G/GR/GROUSSE/FusionInventory-Agent-%{version}%{?prever}.tar.gz
-Source1: %{name}.cron
+Source0:
https://github.com/fusioninventory/fusioninventory-agent/archive/%{version}.tar.gz
+Source1: %{name}.cron
#Source2: %{name}.init
#Source3: %{name}.service
@@ -163,7 +163,7 @@ Requires: perl(Parse::EDID)
%description task-inventory
fusioninventory-task-inventory
%prep
-%setup -q -n FusionInventory-Agent-%{version}%{?prever}
+%setup -q -n %{name}-%{version}%{?prever}
# This work only on older version, and is ignored on recent
cat < - 2.3.17
+- new version
+- Upstream switch to github, minor spec adaptation
Please reconsider the change and pick up tarballs from cpan.org.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Discontinuing perl-Mail-GnuPG
Hi, I indent to discontinue and remove perl-Mail-GnuPG from Fedora. It FTBFS on rawhide, because it seem to suffer from compatibility issues with gnupg2 >= 2.1.5 [1]. AFAIS, nothing in Fedora uses it, so this step probably won't do much harm. Should gnupg2 in Fedora < 23 be updated, perl-Mail-GnuPG will rendered dysfunctional there. I could add "Requires: gnupg2 < 2.1.5" there but this is something I'd rather not do. Ralf [1] https://bugzilla.redhat.com/show_bug.cgi?id=1234738 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Net-Twitter
On 01/30/2015 01:40 PM, Petr Pisar wrote: On Fri, Jan 30, 2015 at 01:13:27PM +0100, Ralf Corsepius wrote: On 01/29/2015 02:36 PM, Emmanuel Seyman wrote: * Ralf Corsepius [29/01/2015 12:03] : Seems to me, as if this package is victim of rpm's perl-package dependency generator adding a bogus "R: perl(authentication)". Indeed. I'm certain the error is caused by line 1320 of lib/Net/Twitter/Role/API/REST.pm: require authentication. (which is the second half of a sentence). This bug is more interesting than I initially thought. When building the same rpm in mock for f20 or f21, the resulting rpms do not carry this bogus "Require: perl(authentication)". This only happens for rawhide. i.e. something in rpm, mock or perl has regressed - Ideas, anyone? My weekly rebuilds show the change between 2014-12-16 and 2015-01-06 <https://ppisar.fedorapeople.org/perl_rebuild/scratch/2015-01-06/index.xhtml#pperl-Net-Twitter>. Difference between build roots reveals, besides other things, upgrading perl-generators from 1.01 to 1.02. You are right on the spot - I rebuilt perl-Net-Twitter in f21 mock-chroots with perl-generators-1.00, perl-generators-1.01, perl-generators-1.02. The regression appears when using perl-generators-1.02. => The origin is the changes between perl-generators-1.01 and perl-generates-1.02. Jitka? Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Net-Twitter
On 01/29/2015 02:36 PM, Emmanuel Seyman wrote: * Ralf Corsepius [29/01/2015 12:03] : Seems to me, as if this package is victim of rpm's perl-package dependency generator adding a bogus "R: perl(authentication)". Indeed. I'm certain the error is caused by line 1320 of lib/Net/Twitter/Role/API/REST.pm: require authentication. (which is the second half of a sentence). This bug is more interesting than I initially thought. When building the same rpm in mock for f20 or f21, the resulting rpms do not carry this bogus "Require: perl(authentication)". This only happens for rawhide. i.e. something in rpm, mock or perl has regressed - Ideas, anyone? Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Net-Twitter
On 01/29/2015 09:14 AM, build...@fedoraproject.org wrote: perl-Net-Twitter has broken dependencies in the rawhide tree: On x86_64: perl-Net-Twitter-4.01008-1.fc22.noarch requires perl(authentication) On i386: perl-Net-Twitter-4.01008-1.fc22.noarch requires perl(authentication) On armhfp: perl-Net-Twitter-4.01008-1.fc22.noarch requires perl(authentication) Please resolve this as soon as possible. Seems to me, as if this package is victim of rpm's perl-package dependency generator adding a bogus "R: perl(authentication)". I.e. I would assume this package needs to be added a filter to filter out "R: perl(authentication)" Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: why does perl-ExtUtils-MakeMaker depend on systemtap-sdt-devel?
On 09/10/2014 08:24 PM, Adam Jackson wrote:
On Wed, 2014-09-10 at 12:32 -0400, Robert P. J. Day wrote:
possibly admitting my ignorance, but why does installing
perl-ExtUtils-MakeMaker drag in systemtap-sdt-devel? i see no logical
connection, and i don't even have any systemtap packages installed.
i ask since i'm working with a software package that fails to
configure properly if the header file "sys/sdt.h" is installed on the
development system, but it needs the MakeMaker package, so i'm in a
bit of a dilemma.
Coincidence of events. I hit the same issue yesterday when trying rt-4
on f21 for the first time ;)
When in doubt:
$ echo n | sudo yum install --releasever=21 --installroot=/tmp/empty foo
And then examine the output. In this case, perl-ExtUtils-MakeMaker →
perl-ExtUtils-Install → perl-devel → systemtap-sdt-devel. Which appears
to have been so since December 2010:
Yes, it's perl-devel which pulls in systemtap-sdt-devel
But, I think there are a couple of bogus deps on perl-devel in some of
the perl package's sub-packages, which are causing the dependency bloat e.g:
perl-ExtUtils-CBuilder
perl-ExtUtils-Embed
perl-ExtUtils-Install
perl-ExtUtils-MakeMaker
perl-ExtUtils-ParseXS
perl-Module-Build
I don't think any of these should R: "perl-devel"
(f21-patch enclosed below).
Ralf
diff --git a/perl.spec b/perl.spec
index 642f6ab..c2aca19 100644
--- a/perl.spec
+++ b/perl.spec
@@ -745,7 +745,6 @@ Epoch: 1
Version:2.49
Requires: %perl_compat
Requires: %{name}-Encode = %{epoch}:%{version}-%{release}
-Requires: perl-devel
BuildArch: noarch
%description Encode-devel
@@ -799,7 +798,6 @@ License:GPL+ or Artistic
Epoch: 1
# real version 0.280210 https://fedoraproject.org/wiki/Perl/Tips#Dot_approach
Version:0.28.2.10
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
@@ -815,7 +813,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:1.30
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
@@ -829,7 +826,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:1.59
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
@@ -844,7 +840,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:6.66
-Requires: perl-devel
Requires: %perl_compat
Requires: perl(Data::Dumper)
Requires: perl(DynaLoader)
@@ -875,7 +870,6 @@ Group: Development/Languages
License:GPL+ or Artistic
Epoch: 0
Version:1.63
-Requires: perl-devel
Requires: %perl_compat
Requires: perl(File::Path)
BuildArch: noarch
@@ -892,7 +886,6 @@ License:GPL+ or Artistic
# Epoch bump for clean upgrade over old standalone package
Epoch: 1
Version:3.18
-Requires: perl-devel
Requires: %perl_compat
BuildArch: noarch
Obsoletes: perl-ExtUtils-Typemaps
@@ -1223,7 +1216,6 @@ Requires: perl(Archive::Tar) >= 1.08
Requires: perl(CPAN::Meta) >= 2.110420
Requires: perl(ExtUtils::CBuilder) >= 0.15
Requires: perl(ExtUtils::ParseXS) >= 1.02
-Requires: perl-devel
Requires: %perl_compat
# Optional run-time needed for generating documentation from POD:
Requires: perl(Pod::Html)
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Email-Abstract/epel7] Do not BR packages that are not present in el7
On 03/07/2014 03:03 PM, Lubomir Rintel wrote:
commit 6154c8d5bf3654510f44dce7f86edc87113acab5
Author: Lubomir Rintel
Date: Fri Mar 7 15:02:58 2014 +0100
Do not BR packages that are not present in el7
perl-Email-Abstract.spec | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
---
diff --git a/perl-Email-Abstract.spec b/perl-Email-Abstract.spec
index ee6f5cd..ad6336d 100644
--- a/perl-Email-Abstract.spec
+++ b/perl-Email-Abstract.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Abstract
Version:3.007
-Release:1%{?dist}
+Release:1%{?dist}.1
Summary:Unified interface to mail representations
Group: Development/Libraries
License:GPL+ or Artistic
@@ -17,8 +17,11 @@ BuildRequires: perl(Test::More) >= 0.96
BuildRequires: perl(lib)
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
-BuildRequires: perl(Mail::Message), perl(Scalar::Util)
+BuildRequires: perl(Scalar::Util)
+%if 0%{?rhel} == 0
+BuildRequires: perl(Mail::Message)
BuildRequires: perl(Email::MIME)
+%endif
Are you sure this step is helpful?
These requirements also are run-time requirements, which means all you
are doing is to remove BR: which expose runtime-requirements,
but actually are shipping a crippled package.
IMO, the correct fix would be to add the missing perl-modules to rhel
and not to remove these BRs.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
EPEL: perl-Class-MethodMaker licensing issue
Hi, Upstream Class-MethodMaker has identified a (minor) licensing issue with code in its testsuite: https://github.com/renormalist/class-methodmaker/issues/2 This licensing issue was fixed upstream in Class-MethodMaker-2.20 (They removed the offending files), which I am currently about to import into Fedora. However, the versions of perl-Class-MethodMaker in EPEL are orphaned (I do not maintain the versions in EPEL) and severely out-dated, but also suffer from this issue. I have no idea what to do about it. Filing a BZ against the package will likely end up being assigned to me, which obviously isn't helpful. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 06:26 PM, Till Maas wrote: On Wed, Feb 05, 2014 at 03:18:04PM +0100, Ralf Corsepius wrote: It's not about indiviiduals it's about defaults and it's about the harm your defaults are causing: 1000s of emails plastering various mailing lists and inboxes. Actually I do not care whether or not perl packages are monitored. But the current situation does not seem to cause much harm, because there is hardly any negative feedback about the current situation. Not unlikely. People maintaining only a few packages will only receive a few mail. I am receiving many of them, often duplicates and triple from various origins + followups from bugzilla + koji. All in all they are adding a significant contribution to the SPAM flood koji & Co already are emitting. If you want to get an imagination, about the amount I am receiving, check out the perl-list's archive: https://lists.fedoraproject.org/pipermail/perl-devel/2014-February/date.html and imagine you'd receive all of these mails 2-3 times. Also enough maintainers cared to add about 800 packages manually to the monitoring system. Well, I guess these "800" packages condense down to a very small number of individuals. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 01:21 PM, Till Maas wrote: On Wed, Feb 05, 2014 at 12:46:58PM +0100, Ralf Corsepius wrote: On 02/05/2014 12:44 PM, Till Maas wrote: If someone does not want notifications for their packages, they can add their name to this list: https://fedoraproject.org/wiki/Upstream_release_monitoring#Package_Owner_Ignore_List IMO, such stuff MUST be opt-in, not opt-out. I added your username already a long time ago, so you/your packages are not affected. It's not about indiviiduals it's about defaults and it's about the harm your defaults are causing: 1000s of emails plastering various mailing lists and inboxes. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 12:44 PM, Till Maas wrote: On Wed, Feb 05, 2014 at 12:36:12PM +0100, Petr Pisar wrote: On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Not all packages are from CPAN, not all maintainers want to receive upstream updates. If someone does not want notifications for their packages, they can add their name to this list: https://fedoraproject.org/wiki/Upstream_release_monitoring#Package_Owner_Ignore_List IMO, such stuff MUST be opt-in, not opt-out. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Upstream releases monitoring globbing support?
On 02/05/2014 12:36 PM, Petr Pisar wrote: On Wed, Feb 05, 2014 at 06:51:43PM +0800, Christopher Meng wrote: Good news to hear that cnucnu has supported glob, I've seen Jens has enabled all hackage packages from a horrible long list to ghc-* one line only. Should we do this for Perl packages also? Not all packages are from CPAN, Also, CPAN is not free of bugs. > not all maintainers want to receive upstream updates. Well, I do not want to receive such update notification mails, because they significantly contribute the mail traffic, I am already receiving. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Perl packaging guidelines
On 07/08/2013 02:25 PM, Petr Šabata wrote:
Dear list,
Following the recent thread on the Packaging list [1], and
since those questions arise fairly often during reviews, I
think it'd be a good idea to discuss some possible updates to
our packaging guidelines.
We all have different opinions on Perl packaging but I'd like to
find some common ground and set some standard how to do things
to unify our style.
I think there is only one group of perl packagers whose opinion is
different from the rest ;)
First, the dependencies, both build- and run-time.
Personally I like to list every module which is actually used
since this means the package only fails to build when
there's an actual issue, not just a change in the dependency
chain.
This sentence is not precisely enough formulated to be able to comment.
I also think not listing some modules only because
it's unlikely they'd get removed from core makes packaging
harder and more confusing, rather than the opposite.
I vehemently disagree.
When perl modules move away, they break building - I.e. these can easily
be re-added at any time, when necessary.
Conversely, adding "everything", only meas to reflect the dependency
state which was valid at one single point in time.
As the work-load and effect related to tracking theses is significant,
pn the longer run, these dependencies state will gradually and silently
diverge from the actual dependencies. I.e. all this does is to add
redundency and dependency bloat.
=> lower packaging quality.
Second, the %{__perl} macro.
What are the benefits of using this (subjectively) ugly macro
compared to simple 'perl'?
The benefits will show when
a) the path to perl should change.
b) the name of the perl program will change.
In both cases, all packages using a hard coded /usr/bin/perl will break.
Plain "perl" contradicts the principles of "deterministic builds":
Simply install a script named "perl" somewhere on your $PATH and run
"rpmbuild" with a spec using "plain perl".
Third, the MODULE_COMPAT macro.
Currently our guidelines enforce the following form:
perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
I propose the following forms are also accepted (the latter
two in case we accept simple 'perl' too):
perl(:MODULE_COMPAT_%(eval "$(%{__perl} -V:version)"; echo $version))
perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
perl(:MODULE_COMPAT_%(eval "$(perl -V:version)"; echo $version))
That's topic 2) from your list.
Fourth, ExtUtils::MakeMaker vs Module::Build.
Module::Build is currently being deprecated and removed from
core, ExtUtils::MakeMaker becoming, once again, the preferred
way. Our guidelines should be updated to reflect that.
Sigh, you can not remove any perl module from Fedora, which is still in use.
I.e. no matter how much you want to remove it, no matter how much
upstream wants to see it removed/deprecated, these modules need to stay
in Fedora at least until no package in Fedora uses it.
And fifth, installation paths.
I suppose the guidelines should explicitly state the vendor
paths should be used.
That's all I can think of now. Please, do share your views.
Also, what would you like to change or improve?
IMO, that's a completely different topic, which is beyond the scope of
this threat.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-POE-Component-IRC] Obsolete tests < v2.81
On 11/26/2012 12:56 PM, Petr Šabata wrote:
commit 5c9e45ac43c9767ac48e72884a292fe968fb61c4
Author: Petr Šabata
Date: Mon Nov 26 12:56:14 2012 +0100
Obsolete tests < v2.81
perl-POE-Component-IRC.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-POE-Component-IRC.spec b/perl-POE-Component-IRC.spec
index 7da7f92..ff6641a 100644
--- a/perl-POE-Component-IRC.spec
+++ b/perl-POE-Component-IRC.spec
@@ -12,7 +12,7 @@
Name: perl-POE-Component-IRC
Summary:A POE component for building IRC clients
Version:6.81
-Release:1%{?dist}
+Release:2%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/B/BI/BINGOS/POE-Component-IRC-%{version}.tar.gz
@@ -63,7 +63,7 @@ Requires: perl(POE::Session)
Requires: perl(POE::Wheel::ReadWrite)
Requires: perl(POE::Wheel::SocketFactory)
# Added during f19 development cycle
-Obsoletes: %{name}-tests
+Obsoletes: %{name}-tests < 2.81
I guess, you actually want this to be "<= 6.81" and not "< 2.81".
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Test-Taint] Specify all dependencies. Drop %%defattr, redundant since rpm 4.4. Fix mixed use of spaces and tabs.
On 10/25/2012 02:22 PM, Marcela Mašláňová wrote: commit 898b2561d529876cf6f4e340b04b033d0b1e5653 Author: Marcela Mašláňová +* Thu Oct 25 2012 Jitka Plesnikova - 1.04-19 +- Specify all dependencies +- Drop %%defattr, redundant since rpm 4.4 +- Fix mixed use of spaces and tabs Marcela or Jitka, whoever might be abusing his Fedora privileges - Stop this absurd stylishness. Your changes to my packages do not fix any bugs and are mere stylishness - These changes are not welcome. If Fedora was having blacklists, I now would blacklist you both. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [Fedora-packaging] [perl-Coro] Work-aroung missing libecb package on build-triggering host
On 10/22/2012 05:34 PM, Petr Pisar wrote:
On Mon, Oct 22, 2012 at 10:14:25AM -0500, Rex Dieter wrote:
On 10/22/2012 10:06 AM, Ralf Corsepius wrote:
On 10/22/2012 03:47 PM, Petr Pisar wrote:
commit e00f8293097f8331883f1df35f74be70fbb290b9
Author: Petr Písař
Date: Mon Oct 22 15:46:27 2012 +0200
Work-aroung missing libecb package on build-triggering host
perl-Coro.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Coro.spec b/perl-Coro.spec
index 50a855d..31589a5 100644
--- a/perl-Coro.spec
+++ b/perl-Coro.spec
@@ -35,7 +35,7 @@ Requires: perl(EV) >= 3
Requires: perl(Event) >= 1.08
Requires: perl(Guard) >= 0.5
Requires: perl(Storable) >= 2.15
-Provides: bundled(libecb) = %(rpm -q libecb --qf '%{VERSION}')
+Provides: bundled(libecb)%(rpm -q libecb --qf ' = %{VERSION}'
2>/dev/null)
I could be wrong, but IIRC, calling rpm inside of rpm specs is not
allowed in Fedora.
Apart of this, what you are doing is rendering your built
non-deterministic - Another "strictly forbidden" item.
Agreed. What you're trying to say essentially is that the bundled
libecb version matches the system/non-bundled version, which really
doesn't make any sense. I'd suggest you simply remove the
versioning (or list the real bundled version some other way).
This is something like static library. Thus code gets frozen into the package
at build-time. So I concluded it's good idea to know which version of the
library the binary package incorporates.
However if you think this is bad idea I will remove it.
Yes, I do - I am insisting on the rpm calls to be removed.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Coro] Work-aroung missing libecb package on build-triggering host
On 10/22/2012 03:47 PM, Petr Pisar wrote:
commit e00f8293097f8331883f1df35f74be70fbb290b9
Author: Petr Písař
Date: Mon Oct 22 15:46:27 2012 +0200
Work-aroung missing libecb package on build-triggering host
perl-Coro.spec |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/perl-Coro.spec b/perl-Coro.spec
index 50a855d..31589a5 100644
--- a/perl-Coro.spec
+++ b/perl-Coro.spec
@@ -35,7 +35,7 @@ Requires: perl(EV) >= 3
Requires: perl(Event) >= 1.08
Requires: perl(Guard) >= 0.5
Requires: perl(Storable) >= 2.15
-Provides: bundled(libecb) = %(rpm -q libecb --qf '%{VERSION}')
+Provides: bundled(libecb)%(rpm -q libecb --qf ' = %{VERSION}'
2>/dev/null)
I could be wrong, but IIRC, calling rpm inside of rpm specs is not
allowed in Fedora.
Apart of this, what you are doing is rendering your built
non-deterministic - Another "strictly forbidden" item.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: File perl-5.16.1-228.fc19.src.rpm uploaded to lookaside cache by jplesnik
On 08/10/2012 09:51 AM, Jitka Plesnikova wrote: A file has been added to the lookaside cache for perl: f29260d492212692f7d005af19e980b4 perl-5.16.1-228.fc19.src.rpm Errm, ... guess you are aware, this commit was a mistake? src.rpms are not supposed to be in the lookaside cache. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Perl-Critic] Do not use Test::Kwalitee on RHEL >= 7
On 04/24/2012 07:42 PM, Paul Howarth wrote: On Tue, 24 Apr 2012 18:09:35 +0200 Ralf Corsepius wrote: On 04/24/2012 05:10 PM, Petr Pisar wrote: commit 69efbb099367a7ff6a35107cc3079a02a8e599f5 Author: Petr Písař Date: Tue Apr 24 15:38:58 2012 +0200 Do not use Test::Kwalitee on RHEL>= 7 Why? In general, dropping tests is a short-sighted idea. Because perl-Perl-Critic will be part of RHEL-7 and perl-Test-Kwalitee won't. So in order for RHEL-7 to be self-hosting, it can't BR: Test::Kwalitee. > Test::Kwalitee will no doubt end up in EPEL-7. In other words, perl-Perl-Critic will not receive full testing in RHEL because RHEL can't use packages from epel7, brilliant idea ;) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Bot-BasicBot
On 01/20/2012 01:39 PM, Petr Šabata wrote:
On Fri, Jan 20, 2012 at 01:34:49AM +, build...@fedoraproject.org wrote:
perl-Bot-BasicBot has broken dependencies in the rawhide tree:
On x86_64:
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title)
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple)
On i386:
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title)
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple)
Please resolve this as soon as possible.
Seems like yet another rpmbuild bug to me...
https://bugzilla.redhat.com/show_bug.cgi?id=783442
Adding
%{?perl_default_filter}
to your spec fixes this.
Seems to me as if %{?perl_default_filter} is (still) mandatorily required.
Ralf
PS: rpm still seems to be parsing comments.
Adding
# %{?perl_default_filter}
also causes the examples to be filtered out.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages with inactive owners orphaned and inactive comaintainers removed
On 01/11/2012 10:07 AM, Petr Pisar wrote: On Wed, Jan 11, 2012 at 09:51:32AM +0100, Ralf Corsepius wrote: On 01/11/2012 09:26 AM, Marcela Mašláňová wrote: On 01/11/2012 05:18 AM, Toshio Kuratomi wrote: Note that the perl-sig pseudo-user could own the packages if the perl-sig wants to continue maintaining them and doesn't want them orphaned. That works right now. What it wouldn't grant is commit rights to the packages. So, pseudo-user wouldn't work well... I don't see any reason why it would not. What about regular PGP key and password changes? Wouldn't perl-sig find guilty on next clean-up and removed of the ownership? I don't understand what you are trying to express. perl-sig mails go to the perl mailing list, anybody interested can listen and step in. It's what several persons who are subscribed to the perl-list seem to have done for a long time - E.g. I do. Only the ones who are rights to commit. ?!? All mails stemming from packages with perl-sig as maintainer or co-maintainer would have to go to the perl-devel list. I.e. to sum up: Actually nothing would change to you and nothing would change many of the "perl-sig" maintainers. There would be a problem that nobody would be personally responsible for a package. You are presuming there is a need to have a personal "responsibility". The purpose of "collaborative maintenance" is to abandon this tie and to replace it with a "group responsibility". Also there could be problems with synchronisation between unassigned volunteering perl-sig members. Sure, ... but in practice, coordination of such efforts rarely is a problem in case of "incident response". They are typicallly resolved via bugzilla or email. I think it's better when each package is owned by a real person. I don't agree. Like in real life, all tasks beyond a certain size require to team up and can not be handled by single individuals anymore. That said, to me, maintaining several hundreds of perl packages by single individuals is impossible and inevitably requires to team up. Surely, for you, a person, whom I assume to be being paid full time for maintaining perl packages, the threshold of number of perl-packages you can handle is higher than that of people (like me), who do so as volunteered side-job in their spare time. Nevertheless your capabilities/resources are limited also. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages with inactive owners orphaned and inactive comaintainers removed
On 01/11/2012 09:26 AM, Marcela Mašláňová wrote: On 01/11/2012 05:18 AM, Toshio Kuratomi wrote: On Wed, Jan 11, 2012 at 04:36:24AM +0100, Ralf Corsepius wrote: I was under the impression, it's the perl-sig's intention to have packages which loose its primary maintainer, to be "colaboratively" maintained. It's at least how I remember the situation when JPO had quit and had left 100s of packages behind. IIRC, back then, packages having had a co-maintainer had been assigned to the 1st co-comaintainer or somebody having stood up to voluneer filling the gap. Those remaining without maintainer were assigned to "spot as placeholder", because the packagedb wasn't able to cope with "maintainer == perl-sig". I guess the packagedb situation hasn't sufficiently improved since then? Correct. No one has spent any time to allow groups to be owners. This would be a significant rearchitecting so I haven't assigned it as an EasyFix task to anyone who has just arrived in infrastructure. Note that the perl-sig pseudo-user could own the packages if the perl-sig wants to continue maintaining them and doesn't want them orphaned. That works right now. What it wouldn't grant is commit rights to the packages. So, pseudo-user wouldn't work well... I don't see any reason why it would not. perl-sig mails go to the perl mailing list, anybody interested can listen and step in. It's what several persons who are subscribed to the perl-list seem to have done for a long time - E.g. I do. Also, in cases nobody steps up and takes action, you (who is subscribed to the perl-list) could step up in any case. I.e. to sum up: Actually nothing would change to you and nothing would change many of the "perl-sig" maintainers. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages with inactive owners orphaned and inactive comaintainers removed
On 01/11/2012 03:30 AM, Toshio Kuratomi wrote: As part of the announced cleanup after the mass password and ssh key reset, packages that had owners who were inactive at this time were orphaned. comaintainer who were inactive were likewise removed from packages. The list of orphaned packages is here: https://fedorahosted.org/fedora-infrastructure/attachment/ticket/3046/to-be-orphaned.txt The list of packages that lsot comaintainers is here: https://fedorahosted.org/fedora-infrastructure/attachment/ticket/3046/to-be-losing-comaints.txt The perl-* packages owned by cweyl were reassigned ownership to mmaslano, one of the comaintainers under the assumption that this was what the perl team would desire. I was under the impression, it's the perl-sig's intention to have packages which loose its primary maintainer, to be "colaboratively" maintained. It's at least how I remember the situation when JPO had quit and had left 100s of packages behind. IIRC, back then, packages having had a co-maintainer had been assigned to the 1st co-comaintainer or somebody having stood up to voluneer filling the gap. Those remaining without maintainer were assigned to "spot as placeholder", because the packagedb wasn't able to cope with "maintainer == perl-sig". I guess the packagedb situation hasn't sufficiently improved since then? Anyway, I just noticed the iburrell packages also are on your list. IMO, these should likely followup the "cweyl treatment", because much of perl would not be usable without them. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages to be orphaned
On 01/09/2012 02:09 PM, Petr Šabata wrote: On Sun, Jan 08, 2012 at 02:21:07PM +0100, Emmanuel Seyman wrote: Hi, all. As you probably know, a significant number of packages are going to be orphaned on Tuesday, some of them perl-related. I'm interested in a few of these so I'll be applying for: perl-App-* perl-CGI-* perl-Config-* perl-CSS-* perl-FCGI-* perl-Fedora-Bugzilla perl-HTML-* perl-HTTP-* perl-JSON* perl-PSGI perl-URI-* perl-WWW-* Okay, I'll leave those to you ;) I might take List::*, Net::*, Term::*, Text::*, XML::*, and possibly POE::*. There are some huge groups, such as Catalyst, DateTime, or MooseX. Anybody interested in those? I'd volunteer to take over and/or co-maintain those of the cweyl packages which are in rt's dependency tree. Haven't checked yet which this would be ;) Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages affected by RPM 4.9 filtering [was: News from rebuild]
On 07/22/2011 06:42 PM, Petr Sabata wrote: > On Fri, Jul 22, 2011 at 06:27:07PM +0200, Ralf Corsepius wrote: >> On 07/22/2011 03:56 PM, Petr Pisar wrote: >> >> Can we have some detailed documentation of "rpm 4.9's dependency >> filtering and some detailed explanations of what we are supposed to do? >> >> So far, I am far from having understood what is going and could not be >> further away from being impressed >> >> Ralf > > It looks ugly, doesn't it? Yes, it hardly could look worse and (IMHO) hardly could be worse. Provided we had been forced to change dependency filtering before F15 (Of course widely undocumented) and we now are being forced to change things again (of course widely undocumented, once again), makes me have doubts on how certain people are working. Openly said, I'd strongly suggest these people to write detailed documentation, converters or similar, ASAP, or RH's management should feel advised to give these people better opportunities to make carrieres _elsewhere_. > I think this is the thing to look at... > https://fedorahosted.org/fpc/ticket/76 > > Also check out already modified packages for inspiration. You can use both > old > and new style filters in one spec file, they should not interfere, as far as I > know. Yes, elegance and ease of use is something very different than this. Openly said, I feel, things are FUBAR'ed. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packages affected by RPM 4.9 filtering [was: News from rebuild]
On 07/22/2011 03:56 PM, Petr Pisar wrote: > On Thu, Jul 21, 2011 at 11:08:40AM +0200, Petr Pisar wrote: >> List of perl packages whose spec file contains `filter_setup' string >> follows. These packages can be affected by transition to RPM 4.9 dependency >> filtering. We advise to migrate the filters after merging perl-5.14 into >> rawhide to get proper results. Also we advise to run rpmdiff on old and new >> package to check your spec file changes takes effect. Please note the list >> was generated from older git repositories mirror, so it does not reflect >> current state exactly. >> >> -- Petr >> >> ikiwiki >> lcgdm >> libdigidocpp >> mhonarc >> mod_perl >> perl-Ace >> perl-AnyEvent >> perl-Apache-DBI-Cache >> perl-AppConfig >> perl-App-cpanminus >> perl-autobox >> perl-Bio-Graphics >> perl-bioperl >> perl-Catalyst-Controller-FormBuilder >> perl-CGI >> perl-CHI >> perl-Class-Prototyped >> perl-Class-XSAccessor >> perl-Contextual-Return >> perl-Crypt-SSLeay >> perl-Data-TreeDumper-Renderer-GTK >> perl-DateTime > > So far, I checked and updated all this packages. > > Followings are not checked. > >> perl-DateTime-Format-Mail >> perl-DateTime-Precise >> perl-DateTime-Set >> perl-DBD-CSV >> perl-DBI-Dumper >> perl-DBIx-Class-Cursor-Cached >> perl-DBIx-ContextualFetch >> perl-Devel-Caller >> perl-Devel-CheckOS >> perl-ExtUtils-XSpp >> perl-File-ChangeNotify >> perl-File-FnMatch >> perl-File-Listing >> perl-File-PathList >> perl-File-ShareDir-PAR >> perl-Goo-Canvas >> perl-Gtk2-Ex-Carp >> perl-HTTP-Cookies >> perl-HTTP-Daemon >> perl-HTTP-Message >> perl-HTTP-Negotiate >> perl-Kwiki >> perl-Kwiki-NewPage >> perl-Kwiki-Raw >> perl-Kwiki-RecentChanges >> perl-Kwiki-Revisions >> perl-Kwiki-Search >> perl-Kwiki-UserName >> perl-Kwiki-UserPreferences >> perl-Kwiki-Users-Remote >> perl-Language-Functional >> perl-libwww-perl >> perl-LWP-Protocol-https >> perl-Math-Random-MT-Auto >> perl-Math-Symbolic >> perl-Memoize-ExpireLRU >> perl-Module-Mask >> perl-MogileFS-Utils >> perl-MooseX-CascadeClearing >> perl-MooseX-Types-DateTimeX >> perl-NetAddr-IP >> perl-Padre >> perl-PathTools >> perl-PDL >> perl-Perl-Critic-Deprecated >> perl-Perl-Critic-More >> perl-Perl-Critic-Pulp >> perl-Perl-Critic-Swift >> perl-Perlilog >> perl-Perl-Metrics-Simple >> perl-POE-Filter-HTTP-Parser >> perl-PPI >> perl-PPI-PowerToys >> perl-PPIx-EditorTools >> perl-PPIx-Regexp >> perl-Pugs-Compiler-Rule >> perl-SOAP-Lite >> perl-Spoon >> perl-Spreadsheet-WriteExcel >> perl-Statistics-Basic >> perl-STD >> perl-Template-Toolkit >> perl-Test-DistManifest >> perl-Test-Perl-Critic-Progressive >> perl-Test-Smoke >> perl-Text-Aligner >> perl-Text-Table >> perl-Unicode-String >> perl-version >> perl-WWW-Curl >> perl-WWW-RobotRules >> perl-Wx >> perl-XML-Parser >> perl-XML-Twig >> perl-YUM-RepoQuery >> redland-bindings >> rt3 > > -- Petr Can we have some detailed documentation of "rpm 4.9's dependency filtering and some detailed explanations of what we are supposed to do? So far, I am far from having understood what is going and could not be further away from being impressed Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl-Class-MOP broken dependencies
On 05/01/2011 09:07 AM, Iain Arnell wrote: > On Sun, May 1, 2011 at 8:51 AM, Ralf Corsepius wrote: >> Hi, >> >> could somebody explain, what is going on with perl(Class::MOP) in >> fedora-15, causing dozens broken dep warnings similar to this: >> >> On 05/01/2011 12:51 AM, build...@fedoraproject.org wrote: >>> perl-CHI has broken dependencies in the F-15 tree: >>> On x86_64: >>>perl-CHI-0.44-3.fc15.noarch requires perl(Class::MOP) > > > It's because of the Moose 2.0 update. Class::MOP is now part of Moose > itself, so I asked Marcela to retire perl-Class-MOP. Unfortunately, > though, I made another minor update to perl-Moose during the week and > now can't push it to stable until later today. Normal service should > be resumed within a day or two. OK, but ... How could this kind of situation have happened at this point of time and how could this this slip through QA? Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
perl-Class-MOP broken dependencies
Hi, could somebody explain, what is going on with perl(Class::MOP) in fedora-15, causing dozens broken dep warnings similar to this: On 05/01/2011 12:51 AM, build...@fedoraproject.org wrote: > perl-CHI has broken dependencies in the F-15 tree: > On x86_64: > perl-CHI-0.44-3.fc15.noarch requires perl(Class::MOP) > On i386: > perl-CHI-0.44-3.fc15.noarch requires perl(Class::MOP) > On x86_64: > perl-CHI-Test-0.44-3.fc15.noarch requires perl(Class::MOP) > On i386: > perl-CHI-Test-0.44-3.fc15.noarch requires perl(Class::MOP) > Please resolve this as soon as possible. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Kwiki-UserName
On 02/14/2011 10:00 PM, build...@fedoraproject.org wrote: > > > perl-Kwiki-UserName has broken dependencies in the rawhide tree: > On x86_64: > perl-Kwiki-UserName-0.14-14.fc15.noarch requires perl(mixin) > On i386: > perl-Kwiki-UserName-0.14-14.fc15.noarch requires perl(mixin) > Please resolve this as soon as possible. Bug is supposed to be fixed in f15 and f16, however this package currently can't be built for f15 because the bug fix depends on other updated packages which currently are stuck in Fedora's package delay queue. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 02/02/2011 11:43 AM, Paul Howarth wrote:
> On 31/01/11 15:21, Marcela Mašláňová wrote:
>> Hello,
>> because some questions and blocked reviews [1]. I feel that we really
>> need discuss our @INC paths once again. I wrote proposal, which is
>> almost the same as was the one sent to the list few months ago [2].
>>
>> This is only proposal and there are also other possibilities, how to
>> create specific directory for installation of users rpms. I'd like to
>> change this proposal to FPC guidelines maybe for next Fedora, therefore
>> I really like to know your opinions.
>
> First of all, what are presumably typos:
>
> F-15:
>
> @INC:
> /usr/local/lib/perl5 -- for CPAN (site lib)
> /usr/local/share/perl5 -- for CPAN (site arch)
> /usr/lib/perl5/vendor_perl -- 3rd party(vendor lib)
> /usr/share/perl5/vendor_perl -- 3rd party(vendor arch)
> /usr/lib/perl5 -- Fedora (priv lib)
> /usr/share/perl5 -- Fedora (arch lib)
> .
>
> Should surely be:
>
> @INC:
> /usr/local/%{_lib}/perl5 -- for CPAN (site arch)
> /usr/local/share/perl5 -- for CPAN (site lib)
> %{_libdir}/perl5/vendor_perl -- 3rd party(vendor arch)
> /usr/share/perl5/vendor_perl -- 3rd party(vendor lib)
> %{_libdir}/perl5 -- Fedora (arch lib)
> /usr/share/perl5 -- Fedora (priv lib)
> .
>
> I don't really see any great harm in installing modules to perl/core
> directories rather than vendor directories. I also like this nice,
> simple set of paths.
> However, the plan envisages third-party repositories sticking with
> vendor directories and I'm not sure that's going to happen.
Actually I have never seen anybody doing this.
Apart of this this definition of vendor_dir
- Does not match Fedora's practice to install into vendor_dir.
- Violates the FHS. 3rd party's are supposed to install to /opt.
> I thought the conventional structure of having modules bundled with perl
> (the perl core) going to perl/core directories and everything else
> that's packaged (including dual lived modules) going to vendor
> directories made good, intuitive sense, and I think that's what upstream
> intended too.
Agreed.
> Moreover, it seems to be widespread policy elsewhere:
>
> https://wiki.archlinux.org/index.php/Perl_Policy
> http://use.perl.org/~schwern/journal/39246
> https://www.socialtext.net/perl5/index.cgi?hints_for_distributors
> http://www.debian.org/doc/packaging-manuals/perl-policy/
>
> So overall I'm in favour of using the F-15 set of paths (assuming the
> typos are fixed) but sticking with the vendor directories for everything
> apart from the perl core.
Well, IMO
a) these F15 paths are a regression in comparsion to what Fedora<15 had
because they reintroduce vendor_dir.
b) these F15 paths break with Fedora's convention to use vendor_dir to
install Fedora-modules => This proposal would requires inspecting all
perl-module's specs and rebuild them.
c) the setting for vendor_dir is a broken as were its predecessors
(letting the site*dir point to user local makes sense).
I.e. if this convention shall be applied, we need to modifiy and rebuild
all perl-packages which currently install to vendor_dir.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 01/31/2011 04:36 PM, Ralf Corsepius wrote: > On 01/31/2011 04:21 PM, Marcela Mašláňová wrote: >> Hello, >> because some questions and blocked reviews [1]. I feel that we really >> need discuss our @INC paths once again. > > Thanks for trying to launch such a discussion. > > I am blocking these reviews, because I feel redhat.cz has drawn > uncommunicated, arguable and questionable decisions, which are at risk > of to run down Fedora's perl. > >> This is only proposal and there are also other possibilities, how to >> create specific directory for installation of users rpms. I'd like to >> change this proposal to FPC guidelines maybe for next Fedora, therefore >> I really like to know your opinions. > > I promise to read it in depth and to think about it, but I won't have > much time this week. Marcela, what are we supposed to think of the fact you are continuing to accept packages which do not install into vendor_dir? I interpret these actions of yours, as you not being interested in settling the issues, but you wanting to implement facts by brute-force. This is not helpful. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl @INC (paths) again
On 01/31/2011 04:21 PM, Marcela Mašláňová wrote: > Hello, > because some questions and blocked reviews [1]. I feel that we really > need discuss our @INC paths once again. Thanks for trying to launch such a discussion. I am blocking these reviews, because I feel redhat.cz has drawn uncommunicated, arguable and questionable decisions, which are at risk of to run down Fedora's perl. > This is only proposal and there are also other possibilities, how to > create specific directory for installation of users rpms. I'd like to > change this proposal to FPC guidelines maybe for next Fedora, therefore > I really like to know your opinions. I promise to read it in depth and to think about it, but I won't have much time this week. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Patches for CVE-2011-0009
On 01/26/2011 12:00 AM, Xavier Bachelot wrote: > Hi, > > I've been looking at the issue for both rt 3.6 and 3.8. > I have a rather full featured patch for 3.8 and I took the Debian patch > for 3.6. However, I'm not happy with 3.6, it's lacking the script to fix > all the passwords. I'll try to come up with something better in the next > few days. Here's my WIP for reference. Thanks for the patch, Xavier. But, please give people a chance to have a look into it - I am working on this in my spare time (which currently is widle consumed by Fedora QA's delay queue fixing bugs in Fedora a PITA - Sorry, if you find this rude, but this had to be said!) Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Test-SharedFork: 1/2] re-add macros. -tests sub-package was missing during update
On 01/10/2011 09:47 AM, Marcela Mašláňová wrote:
> commit 7ea2316fcdfe97222125cfde576de4fd28265ac8
> Author: Marcela Mašláňová
> Date: Mon Jan 10 09:45:39 2011 +0100
>
> re-add macros. -tests sub-package was missing during update
>
> perl-Test-SharedFork.spec |8 +++-
> 1 files changed, 7 insertions(+), 1 deletions(-)
> ---
> diff --git a/perl-Test-SharedFork.spec b/perl-Test-SharedFork.spec
> index f16d750..88af882 100644
> --- a/perl-Test-SharedFork.spec
> +++ b/perl-Test-SharedFork.spec
> @@ -1,7 +1,7 @@
> Name: perl-Test-SharedFork
> Summary:Fork test
> Version:0.15
> -Release:1%{?dist}
> +Release:2%{?dist}
> License:GPL+ or Artistic
> Group: Development/Libraries
> Source0:
> http://search.cpan.org/CPAN/authors/id/T/TO/TOKUHIROM/Test-SharedFork-%{version}.tar.gz
> @@ -13,6 +13,9 @@ BuildArch: noarch
> BuildRequires: perl(ExtUtils::MakeMaker)>= 6.42
> BuildRequires: perl(Test::More)>= 0.88
>
> +%{?perl_default_filter}
> +%{?perl_default_subpackage_tests}
> +
> %description
> Test::SharedFork is utility module for Test::Builder. It manages testing
> by keeping the test count consistent between parent and child processes.
> @@ -47,6 +50,9 @@ rm -rf %{buildroot}
> %{_mandir}/man3/*.3*
>
> %changelog
> +* Mon Jan 10 2011 Marcela Mašláňová - 0.15-2
> +- re-add macros. -tests sub-package was missing during update
Instead of doing this - and thus continuing to pollute Fedora with
package bloat - you should better should have Obsoleted the *tests packages.
It's what I will be doing in all of my packages from now on (Such as
this one).
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Test-SharedFork/f13/master] re-add macros for tests and filter
On 01/10/2011 08:20 AM, Marcela Mašláňová wrote: > commit 582b9a822d7de8c15d904b47b9917c166912a6c5 > Author: Marcela Mašláňová > Date: Mon Jan 10 08:20:09 2011 +0100 > > re-add macros for tests and filter Why? a) All these perl-*tests do is to cause packaging bloat by packaging stuff which was never meant to be installed (Otherwise the package would do so). Except on very rare occasions, the perl-*tests packages are non-helpful. All they do is causing package bloat and dependency issues. b) The perl filters are only necessary on arch'ed packages to work around rpm inability to filter perl packages correctly. On noarched packages they are a superfluous silliness. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
perl packages's debuginfo clashes
Hi, we are facing severe problems with perl-debuginfo packages: https://bugzilla.redhat.com/show_bug.cgi?id=664414 Unfortunately, I haven no "real idea" what to do about it. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Why does Fedpra's perl need systemtap?
On 12/13/2010 10:33 AM, Marcela Mašláňová wrote: > On 12/12/2010 07:45 AM, Ralf Corsepius wrote: >> >> Sure, we can't avoid RH's addiction to python, but that's not my point. >> >> It's the impact glueing perl and python together has on upgrades, such >> as user-upgrade from Fedora N -> Fedora N+1, or python/perl version jumps. >> >> This impact already is visible when upgrading Fedora 13 to Fedora 14. >> >> That's why I am asking >> * Why does perl need systemtap? >> * What does perl use systemtap for? >> >> So far, I haven't seen any answer to these questions. >> >> > It is possible to ask maintainers of systemtap if it's important to have > everything built with enabled systemtap probes. One should say so > after checking their feature page for F-13 [1]. Perl wasn't mentioned > there, because it didn't have this option yet. > In my opinion answer to both your question is here: > https://fedoraproject.org/wiki/Features/SystemtapStaticProbes#Summary The answers are not there. But I guess, I better should keep my face shut, because wanting to discuss this kind of RH decisions so far has always proven to be a waste of time and an unpleasant experience. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Why does Fedpra's perl need systemtap?
On 12/12/2010 07:11 AM, Iain Arnell wrote: > On Sat, Dec 11, 2010 at 11:31 AM, Ralf Corsepius wrote: >> >> Would you please explain in detail why Fedora's perl needs systemtap and >> what it uses it for? >> >> As I tried to outline in the BZ above, the consequence on perl and >> Fedora are dramatic. > > I think you're over-exaggerating the consequences, Ralf. May-be, one consequence however is perl and python now being glued together. This may have quite some amount of nasty side-effects on major upgrades. > It's not perl that requires systemtap; it's perl-devel that requires > systemtap-sdt-devel. Ideally, almost no-one should need to have > perl-devel installed; Correct. Fact also is, all of us around here hardly can avoid not having it installed, > it should really only be necessary when building > XS modules or linking with libperl. Unfortunately, our packaging is > less than perfect, so a few packages end up pulling in perl-devel > unnecessarily (mostly through Test::Builder and Test::More). Exactly. > I'm going > to take a look at removing some of these where the requirement is > obviously wrong. And for things like SQL-Translator that include their > own test modules, I'd suggest splitting off a separate > perl-Test-SQL-Translator sub-package. > > As for your other concern that systemtap-sdt-devel is pulling in > python, have you ever tried to "yum remove python"? Like it or not, > python is a pretty fundamental requirement in Fedora and will be > present on just about every installation anyway. Sure, we can't avoid RH's addiction to python, but that's not my point. It's the impact glueing perl and python together has on upgrades, such as user-upgrade from Fedora N -> Fedora N+1, or python/perl version jumps. This impact already is visible when upgrading Fedora 13 to Fedora 14. That's why I am asking * Why does perl need systemtap? * What does perl use systemtap for? So far, I haven't seen any answer to these questions. When regarding this from one angle, this is simpla a matter of lack of communication, however when regarding this from a different angle, this leaves room for speculations along the lines of how "@RHs treat the community" rsp. about RH's governance in Fedora. Provided the language certain @RH's used in bugzilla, I for one have little doubts about what is going on. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Why does Fedpra's perl need systemtap?
Marcela, Due to the fact you still haven't answer the questions I rose in https://bugzilla.redhat.com/show_bug.cgi?id=661553 you don't leave me another choice but to ask in public: Would you please explain in detail why Fedora's perl needs systemtap and what it uses it for? As I tried to outline in the BZ above, the consequence on perl and Fedora are dramatic. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rebuild of some perl packages
On 12/11/2010 10:25 AM, Iain Arnell wrote:
> On Fri, Dec 10, 2010 at 5:37 PM, Marcela Maslanova
> wrote:
>> Hello,
>> because of bug in paths (vendorarch), there will be needed
>> rebuild of some packages (~1300). I choose only those
>> which weren't rebuild with vendorarch in Perl. [1]
Would you please elaborate in detail what you are going to do?
If what I gather between the lines of
https://bugzilla.redhat.com/show_bug.cgi?id=661697#c2
I am expecting the worse.
>> I've asked for testing dist tag, so nothing will be
>> broken [2]. Rebuild will start next week.
>
> Is there something in place to avoid the problems we had last time
> with "older" packages from the rebuild tag overriding "newer" packages
> in dist-f15 itself? And is a separate tag really necessary for this?
> Perl is already looking in both core and vendor directories, so there
> should be no breakage due to modules installed in the "wrong" place.
If the intention is to move all packages to %{_libdir}/perl5/vendor_perl
then a separate tag should not be necessary.
> And I'm still not sure what the intended result is meant to be.
So do I. I feel the way the perl maintainers @redhat.cz are
communicating with the community leaves much to be desired.
> Are
> you planning to update all the specs to use privlib/archlib so that
> everything ends up in the core directories? Or keeping
> vendorlib/vendorarch and merely rebuilding to move the modules out of
> the core directories again?
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide vendorarch?
On 12/09/2010 03:01 PM, Petr Pisar wrote:
> On Thu, Dec 09, 2010 at 02:35:34PM +0100, Ralf Corsepius wrote:
>> On 12/09/2010 02:27 PM, Petr Pisar wrote:
>>> On Tue, Dec 07, 2010 at 05:19:34PM +0100, Ralf Corsepius wrote:
>>>> On 12/07/2010 04:57 PM, Marcela Mašláňová wrote:
>>
>>>>> If core and vendor are the same as it is in F-14, then it's non-existent
>>>>> module looked up twice in the same path without luck.
>>>>>
>>>>> So, my suggestion is change all modules to install into core directories
>>>>> and leave vendorarch empty for personal RPMs, which also cut down time for
>>>>> looking up
>>>>
>>>> How comes, f14 already did so and f15 has stopped doing so?
>>>>
>>> No, it didn't. See spec files.
>>
>> The facts speak a clear language.
>>
>> All f15-built modules now land in %{_libdir}/perl5/vendor_perl instead
>> of %{_libdir}/perl5 as they did in f14.
>>
> You do not differentiate perl symbolic name and and real path.
No, I always referred to the installation directory and to nothing else.
> Yes, the files
> moved to different directory.
Correct. This is the the regression
> I do not say there is no regression in distribution.
Provided the attitude I experience from certain @RH perl-core
maintainers, it will not be me who will fixes this regression.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide vendorarch?
On 12/09/2010 02:27 PM, Petr Pisar wrote:
> On Tue, Dec 07, 2010 at 05:19:34PM +0100, Ralf Corsepius wrote:
>> On 12/07/2010 04:57 PM, Marcela Mašláňová wrote:
>>> If core and vendor are the same as it is in F-14, then it's non-existent
>>> module looked up twice in the same path without luck.
>>>
>>> So, my suggestion is change all modules to install into core directories
>>> and leave vendorarch empty for personal RPMs, which also cut down time for
>>> looking up
>>
>> How comes, f14 already did so and f15 has stopped doing so?
>>
> No, it didn't. See spec files.
The facts speak a clear language.
All f15-built modules now land in %{_libdir}/perl5/vendor_perl instead
of %{_libdir}/perl5 as they did in f14.
To me, this is a massive regression - period.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
rawhide vendorarch?
Hi, Could somebody explain this change between f14 and f15? f14: perl -V:vendorarch vendorarch='/usr/lib64/perl5'; f15: perl -V:vendorarch vendorarch='/usr/lib64/perl5/vendor_perl'; This causes f15 to install their vendorarch'ed modules under /usr/lib64/perl5/vendor_perl instead of /usr/lib64/perl5 I.e. rebuilding packages under f15/rawhide causes perl-modules to move from /usr/lib64/perl5 to /usr/lib64/perl5/vendor_perl E.g.: # rpm -qlp perl-HTTP-Server-Simple-0.43-1.fc14.noarch.rpm /usr/share/perl5/HTTP/Server/Simple.pm /usr/share/perl5/HTTP/Server/Simple/CGI.pm /usr/share/perl5/HTTP/Server/Simple/CGI/Environment.pm # rpm -qlp perl-HTTP-Server-Simple-0.43-1.fc15.noarch.rpm /usr/share/perl5/vendor_perl/HTTP/Server/Simple.pm /usr/share/perl5/vendor_perl/HTTP/Server/Simple/CGI.pm /usr/share/perl5/vendor_perl/HTTP/Server/Simple/CGI/Environment.pm In generaly, I fail to understand why "vendor_perl" is necessary and why this change was introduced to f15. Also, I am facing FTBS errors, which I suspect to be related to this f14->f15 change and to rawhide currently containing a mixture of perl-packages using vendorarch=/usr/share/perl5 and others vendorarch=/usr/share/perl5/vendor_arch. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
On 09/28/2010 05:38 AM, Ralf Corsepius wrote: > On 09/27/2010 10:51 PM, Bill Nottingham wrote: >> Michael Schwendt (mschwe...@gmail.com) said: >>> The following packages in the repository suffer from broken dependencies: >>> >>> == >>> The results in this summary consider Test Updates! >>> == >>> >>> package: perl-Finance-Quote-1.17-3.fc14.noarch from >>> fedora-14-development-i386 >>> unresolved deps: >>>perl(HTTP::Headers) >>> >>> package: perl-Finance-Quote-1.17-3.fc14.noarch from >>> fedora-14-development-x86_64 >>> unresolved deps: >>>perl(HTTP::Headers) >> >> Huh? Did perl-libwww-perl disappear? > No. Marcela screwed the package. > > Seemingly she is trying to filter out duplicate provides rpm generates > and now filters too much. I just commited a patch which hopefully fixes these issues into git and summitted these packages for fc13 and fc14 testing. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
On 09/27/2010 10:51 PM, Bill Nottingham wrote: > Michael Schwendt (mschwe...@gmail.com) said: >> The following packages in the repository suffer from broken dependencies: >> >> == >> The results in this summary consider Test Updates! >> == >> >> package: perl-Finance-Quote-1.17-3.fc14.noarch from >> fedora-14-development-i386 >>unresolved deps: >> perl(HTTP::Headers) >> >> package: perl-Finance-Quote-1.17-3.fc14.noarch from >> fedora-14-development-x86_64 >>unresolved deps: >> perl(HTTP::Headers) > > Huh? Did perl-libwww-perl disappear? No. Marcela screwed the package. Seemingly she is trying to filter out duplicate provides rpm generates and now filters too much. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Test-Smoke] - 630802 filter Mail::Sendmail from provides, require it from RPM
On 09/07/2010 10:57 AM, Marcela Mašláňová wrote:
> On 09/07/2010 10:51 AM, Paul Howarth wrote:
>> On 07/09/10 07:44, Ralf Corsepius wrote:
>>> On 09/07/2010 08:32 AM, Marcela Mašláňová wrote:
>>>> commit 913e9f58837c3237bd67804e552732e77bb336e7
>>>> Author: Marcela Mašláňová
>>>> Date: Tue Sep 7 08:32:10 2010 +0200
>>>>
>>>>- 630802 filter Mail::Sendmail from provides, require it from RPM
>>>>
>>>> perl-Test-Smoke.spec | 11 ++-
>>>> 1 files changed, 10 insertions(+), 1 deletions(-)
>>>> ---
>>>> diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
>>>> index 2fafd95..023404f 100644
>>>> --- a/perl-Test-Smoke.spec
>>>> +++ b/perl-Test-Smoke.spec
>>>> @@ -1,6 +1,6 @@
>>>> Name: perl-Test-Smoke
>>>> Version:1.43
>>>> -Release:1%{?dist}
>>>> +Release:2%{?dist}
>>>> Summary:Perl core test smoke suite
>>>> License:GPL+ or Artistic
>>>> Group: Development/Libraries
>>>> @@ -10,6 +10,7 @@ BuildRoot:
>>>> %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>>>> BuildArch: noarch
>>>> BuildRequires: perl(ExtUtils::MakeMaker)
>>>> BuildRequires: perl(Test::More)
>>>> +Requires: perl(Mail::Sendmail)
>>>> Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`";
>>>> echo $version))
>>>>
>>>> %description
>>>> @@ -17,6 +18,10 @@ Test::Smoke exports $conf and read_config() by default.
>>>>
>>>> %prep
>>>> %setup -q -n Test-Smoke-%{version}
>>>> +%{?filter_setup:
>>>> +%filter_from_provides /perl(Mail::Sendmail)/d
>>>> +%?perl_default_filter
>>>> +}
>>>>
>>>> %build
>>>> %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
>>>> @@ -34,6 +39,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
>>>> 2>/dev/null \;
>>>> %{_fixperms} $RPM_BUILD_ROOT/*
>>>> rm -rf $RPM_BUILD_ROOT/%{_bindir}/W32Configure.pl
>>>> rm -rf $RPM_BUILD_ROOT/%{_mandir}/man1/W32Configure*
>>>> +rm -rf $RPM_BUILD_ROOT/%{perl_vendorlib}/inc/Mail/Sendmail.pm
>>>>
>>>> %check
>>>> make test
>>>> @@ -58,5 +64,8 @@ rm -rf $RPM_BUILD_ROOT
>>>> %{_mandir}/man3/*
>>>>
>>>> %changelog
>>>> +* Tue Sep 7 2010 Marcela Mašláňová1.43-2
>>>> +- 630802 filter Mail::Sendmail from provides, require it from RPM
>>>> +
>>>
>>> IMO, you are playing with symptoms, because the actual cause is this
>>> package being broken.
>>>
>>> I.e. instead of filtering inc::Mail::Sendmail, this package is broken i
>>> in installing inc/Mail/Sendmail.
>> Marcela seems to have fixed the problem twice: firstly, as you noted, by
>> filtering out the errant provide, and secondly by removing
>> $RPM_BUILD_ROOT/%{perl_vendorlib}/inc/Mail/Sendmail.pm and adding
>> Requires: perl(Mail::Sendmail) instead, which should mean that the
>> filtering isn't needed in the first place.
>>
>> Paul.
>> --
> I created an upstream ticket. I'll try to propose patch for removing
> bundled library, when I have time.
The cause of this problem isn't the source package containing a bundled
perl-module, it is this package installing this bundled library and it
using it (c.f. "grep inc smokeperl.pl", this is all wrong).
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [perl-Test-Smoke] - 630802 filter Mail::Sendmail from provides, require it from RPM
On 09/07/2010 08:32 AM, Marcela Mašláňová wrote:
> commit 913e9f58837c3237bd67804e552732e77bb336e7
> Author: Marcela Mašláňová
> Date: Tue Sep 7 08:32:10 2010 +0200
>
> - 630802 filter Mail::Sendmail from provides, require it from RPM
>
> perl-Test-Smoke.spec | 11 ++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
> ---
> diff --git a/perl-Test-Smoke.spec b/perl-Test-Smoke.spec
> index 2fafd95..023404f 100644
> --- a/perl-Test-Smoke.spec
> +++ b/perl-Test-Smoke.spec
> @@ -1,6 +1,6 @@
> Name: perl-Test-Smoke
> Version:1.43
> -Release:1%{?dist}
> +Release:2%{?dist}
> Summary:Perl core test smoke suite
> License:GPL+ or Artistic
> Group: Development/Libraries
> @@ -10,6 +10,7 @@ BuildRoot:
> %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> BuildArch: noarch
> BuildRequires: perl(ExtUtils::MakeMaker)
> BuildRequires: perl(Test::More)
> +Requires: perl(Mail::Sendmail)
> Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo
> $version))
>
> %description
> @@ -17,6 +18,10 @@ Test::Smoke exports $conf and read_config() by default.
>
> %prep
> %setup -q -n Test-Smoke-%{version}
> +%{?filter_setup:
> +%filter_from_provides /perl(Mail::Sendmail)/d
> +%?perl_default_filter
> +}
>
> %build
> %{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
> @@ -34,6 +39,7 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
> 2>/dev/null \;
> %{_fixperms} $RPM_BUILD_ROOT/*
> rm -rf $RPM_BUILD_ROOT/%{_bindir}/W32Configure.pl
> rm -rf $RPM_BUILD_ROOT/%{_mandir}/man1/W32Configure*
> +rm -rf $RPM_BUILD_ROOT/%{perl_vendorlib}/inc/Mail/Sendmail.pm
>
> %check
> make test
> @@ -58,5 +64,8 @@ rm -rf $RPM_BUILD_ROOT
> %{_mandir}/man3/*
>
> %changelog
> +* Tue Sep 7 2010 Marcela Mašláňová 1.43-2
> +- 630802 filter Mail::Sendmail from provides, require it from RPM
> +
IMO, you are playing with symptoms, because the actual cause is this
package being broken.
I.e. instead of filtering inc::Mail::Sendmail, this package is broken i
in installing inc/Mail/Sendmail.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Config-Model
On 08/19/2010 06:07 PM, Paul Howarth wrote: > On 19/08/10 16:52, build...@fedoraproject.org wrote: >> >> >> perl-Config-Model has broken dependencies in the F-14 tree: >> On x86_64: >> perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any)>= 0:0.303 >> On i386: >> perl-Config-Model-1.205-2.fc14.noarch requires perl(YAML::Any)>= 0:0.303 >> Please resolve this as soon as possible. > > Anybody wanting to see the back of this daily reminder is invited to try > the update: > > https://admin.fedoraproject.org/updates/perl-Config-Model-1.205-4.fc14 > > ... and add some karma. Any reason for not having patched META.yml? Also, perl-Config-Model-1.206 is out (with the broken YAML::Any version still inside). Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl packaging guidelines
On 07/27/2010 06:49 PM, Iain Arnell wrote: > Maybe we should also consider splitting perl-sig mailing list into > separate perl-sig-bug-and-cvs-spam and a real discussion list. Please no. a) We already have way too many lists in Fedora. b) perl-sig members already receive many duplicate mails from various origins. c) One key point behind "cc:-ing" perl-sig is monitoring other perl-packagers' activities. Splitting the list would void this aspect. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide perl-5.12 status
On 07/07/2010 03:21 PM, Marcela Mašláňová wrote: > On 07/07/2010 01:28 PM, Ralf Corsepius wrote: > >> On 07/07/2010 09:37 AM, Marcela Mašláňová wrote: >> >>> On 07/03/2010 08:06 AM, Ralf Corsepius wrote: >>> >>>> An update: >>>> >>>> I filed BZ's on all of those packages which haven't not already been >>>> tracked as FTBS. All of these BZs are tagged as "F14Target" rsp. >>>> F14FTBFS (which indirectly blocks "F14Target"). >>>> >>>> >>> Thank for filing these bugzillas. >>> >> Welcome. ATM, these are still open: >> >> >>>> * BackupPC-3.1.0-14 >>>> >>>>> wants perl-suidperl (Abandoned by perl-5.12.) >>>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=611009 >>> >> Fedora maintainer and upstream maintainer seem to have difficulties in >> understanding the issue and finding a solution. Iain has proposed a >> (IMHO) viable work-around, but no conclusions/results so far. >> >> >>>>> * perl-DBI-Dumper >>>>> Fails to build - Dead upstream. >>>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=555496 >>> FTBS, open since 2010-01-14, no response from maintainer. >>> >> >>>>> * perl-Data-Alias >>>>> Fails to build - Dead upstream. >>>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=611014 >>> >> >>>>> * perl-Pugs-Compiler-Rule >>>>> Fails to build - Dead upstream. >>>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=611015 >>> >> >>>>> * perl-Test-AutoBuild >>>>> Fails to build - Dead upstream >>>>> (Upstream maintainer: Daniel P. Berrangé, >>>>> Fedora maintainer: berra...@fp.org ?!?) >>>>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=539046 >>> FTBS, open since 2009-11-19, no response from maintainer. >>> >> I'd propose to close and abandon the perl-* packages rather "soonish >> than later" and not to wait for "Fedora 14". I.e. I'd propose to set >> these package's maintainers a firm deadline (say, 1-2 weeks from now) >> and then to kill the then remaining perl-modules. >> >> IMO, these package's maintainers and their upstreams knew about these >> packages issues for long enough and had sufficiently often been warned. >> >> Ralf >> > After I gained so much popularity on fedora-devel, I have no courage to > ask rel-eng for another > favour like "remove package, which is not mine". But surely ping > maintainers > to orphan/kill these packages in week or two would be nice. > They all are being pinged daily - All of these packages are included inside of the broken deps reports. > I suppose packages, which won't be fixed, have: A/ dead upstream, B/ > no-one is using them. Therefore I agree with removal. Well, these packages all carry broken deps and are uninstallable in rawhide. I.e. unless they can be fixed, it's only a matter of whether _we_ kill them or whether rel-eng/FTBS will kill them later. > If they were > essential, they would be probably rewritten and re-added later. > As I wrote earlier, I tried to check whether they are used by Fedora, but unless I have missed something, I haven't found any such case. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rawhide perl-5.12 status
An update: I filed BZ's on all of those packages which haven't not already been tracked as FTBS. All of these BZs are tagged as "F14Target" rsp. F14FTBFS (which indirectly blocks "F14Target"). On 06/28/2010 02:19 PM, Ralf Corsepius wrote: > Hi, > > AFAICT, these packages remain to be looked after > > * BackupPC-3.1.0-14 > wants perl-suidperl (Abandoned by perl-5.12.) https://bugzilla.redhat.com/show_bug.cgi?id=611009 > * gnumeric-plugins-extras-1.10.0-1 > Fails to build for reasons outside of Perl. https://bugzilla.redhat.com/show_bug.cgi?id=599888 FTBS, open since 2010-06-03, no response from maintainer. > * perl-DBI-Dumper > Fails to build - Dead upstream. https://bugzilla.redhat.com/show_bug.cgi?id=555496 FTBS, open since 2010-01-14, no response from maintainer. > * perl-Data-Alias > Fails to build - Dead upstream. https://bugzilla.redhat.com/show_bug.cgi?id=611014 > * perl-Pugs-Compiler-Rule > Fails to build - Dead upstream. https://bugzilla.redhat.com/show_bug.cgi?id=611015 > * perl-Test-AutoBuild > Fails to build - Dead upstream > (Upstream maintainer: Daniel P. Berrangé, >Fedora maintainer: berra...@fp.org ?!?) https://bugzilla.redhat.com/show_bug.cgi?id=539046 FTBS, open since 2009-11-19, no response from maintainer. > * virt-v2v: > Fails to build for reasons outside of Perl. > https://bugzilla.redhat.com/show_bug.cgi?id=608389 closed, issue resolved. > * krazy2: > Fails to rebuild for reasons outside of Perl. > https://bugzilla.redhat.com/show_bug.cgi?id=608649 closed, issue resolved. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl 5.12 status - dependency graph - 20100514
On 05/14/2010 04:08 PM, Petr Pisar wrote: > This is list of failed packages against dist-f14-perltest on 2010-05-14. Comments on some packages I had a look into interspersed: > perl-Apache-Session-Wrapper rebuilt > perl-AutoClass false negative ... was successfully built by Marcela on 2010-04-29 > perl-Business-ISBN-Data false negative ... was successfully built by Marcela on 2010-04-29 > perl-Calendar-Simple rebuilt. > perl-CGI-Prototype rebuilt > perl-FreezeThaw rebuilt > perl-opts rebuilt > perl-Regexp-Common false negative ... was successfully built by Marcela on 2010-05-06 > perl-Text-Reform rebuilt > perl-XXX rebuilt Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rpms/perl-Net-UPnP/devel perl-Net-UPnP.spec,1.6,1.7
On 05/13/2010 10:33 AM, Marcela Mašláňová wrote:
> Author: mmaslano
>
> Update of /cvs/pkgs/rpms/perl-Net-UPnP/devel
> In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv23483
>
> Modified Files:
> perl-Net-UPnP.spec
> Log Message:
> * Tue May 04 2010 Marcela Maslanova - 1:1.4.2-3
> - Added BR: perl(version) to fix FTBFS.
>
>
>
> Index: perl-Net-UPnP.spec
> ===
> RCS file: /cvs/pkgs/rpms/perl-Net-UPnP/devel/perl-Net-UPnP.spec,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -u -p -r1.6 -r1.7
> --- perl-Net-UPnP.spec4 May 2010 13:52:24 - 1.6
> +++ perl-Net-UPnP.spec13 May 2010 08:33:39 - 1.7
> @@ -10,6 +10,7 @@ Source0:http://search.cpan.org/CPAN/aut
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> BuildArch: noarch
> BuildRequires: perl(ExtUtils::MakeMaker)
> +BuildRequires: perl(version)
> BuildRequires: perl(Test::More)
> BuildRequires: perl(version)
Note that perl(version) already is a "BuildRequires:".
You have added it a second time.
Ralf
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl 5.12 status
On 05/12/2010 08:08 AM, Ralf Corsepius wrote: > On 05/11/2010 04:39 PM, Ralf Corsepius wrote: >> On 05/11/2010 03:42 PM, Marcela Maslanova wrote: >>> perl-Gtk2-Spell >> This doesn't. > This still doesn't build. I've just applied a patch to make it build with perl-5.12.0 This package now also is in perl-f14-perltest. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl 5.12 status
On 05/11/2010 04:39 PM, Ralf Corsepius wrote: > On 05/11/2010 03:42 PM, Marcela Maslanova wrote: >> perl-Gnome2 >> perl-Gnome2-Canvas >> perl-Gnome2-GConf >> perl-Gnome2-Print >> perl-Gnome2-VFS >> perl-Gnome2-Wnck [..] >> perl-Gtk2-Ex-Dialogs >> perl-Gtk2-GladeXML I rebuilt all of these above in perl-f14-perltest, except of perl-Gtk2-Spell. >> perl-Gtk2-Spell > This doesn't. This still doesn't build. Breakdown logs can be found here: http://koji.fedoraproject.org/koji/taskinfo?taskID=2181966 BTW: On one hand, according to CPAN (http://search.cpan.org/~mlehmann/Gtk2-Spell-1.03/) this package hasn't received any maintainer attention since 2003. Also, buildmatrix http://matrix.cpantesters.org/?dist=Gtk2-Spell+1.03 looks quite frightening. On the other hand, there is a seemingly pretty active "perl-Gtk2" upstream at sourceforge (http://gtk2-perl.sourceforge.net/), who seems to have adopted Gtk::Spell (http://sourceforge.net/projects/gtk2-perl/files/), but seeming hasn't touched it either. Not unlikely a dead exotic and hardly used package, I suppose :) Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: rpms/perl-Date-Simple/EL-6 perl-Date-Simple.spec,1.13,1.14
On 05/11/2010 04:21 PM, Paul Howarth wrote: > Author: pghmcfc > > Update of /cvs/pkgs/rpms/perl-Date-Simple/EL-6 > In directory cvs01.phx2.fedoraproject.org:/tmp/cvs-serv12558/EL-6 > > Modified Files: > perl-Date-Simple.spec > Log Message: > Minor clean-ups > > > Index: perl-Date-Simple.spec > === > RCS file: /cvs/pkgs/rpms/perl-Date-Simple/EL-6/perl-Date-Simple.spec,v > retrieving revision 1.13 > retrieving revision 1.14 > diff -u -p -r1.13 -r1.14 > --- perl-Date-Simple.spec 26 Jul 2009 05:33:20 - 1.13 > +++ perl-Date-Simple.spec 11 May 2010 14:21:45 - 1.14 > -* Thu Feb 26 2009 Fedora Release > Engineering - 3.03-2 > +* Thu Feb 26 2009 Fedora Release > Engineering 3.03-2 > - Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild What are you trying to achieve? I am not aware of any rule mandating " version". Conversely, Fedora has been using - "version" for ages. cf. https://fedoraproject.org/wiki/Packaging:Guidelines That said, IMO, all your changes do is rendering diffs between different distros less readable. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl 5.12 status
On 05/11/2010 04:04 PM, Dave Cross wrote: > On 05/11/2010 02:42 PM, Marcela Maslanova wrote: >> Hello, >> I'm attaching list of failure. Some of them will be still >> fixable by simple rebuild. It's 133 build failures. > >> perl-Calendar-Simple Already adopted ;) > I released version 1.21 of Calendar::Simple purely to address the issue > that tests were failing on 5.11+. > > See http://cpansearch.perl.org/src/DAVECROSS/Calendar-Simple-1.21/Changes Built for rawhide (perl-5.10.0) but not yet for 5.12.0 (dist-f14-perltest). c.f. http://koji.fedoraproject.org/koji/packageinfo?packageID=2790 Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Why perl-*.i686.rpm on x86_64?
On 05/05/2010 04:33 PM, Bill Nottingham wrote: > Bill Nottingham (nott...@redhat.com) said: > >> We certainly did ship earlier perl for both arches; check the F7-F12 >> releases. (Have't checked earlier, but it's been there forever.) >> >> I file a ticket for rel-eng: https://fedorahosted.org/rel-eng/ticket/3695 >>> OK, I realize this ticked was closed immediately. >>> >> It stems from the attached. It may not make sense now that libperl is >> separate; at the time, it wasn't. >> > I've taken the whitelist out in upstream mash; that being said, it's > unlikely that will make F-13 release. (It's not like it causes issues, > afaik.) > OK with me. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Why perl-*.i686.rpm on x86_64?
On 05/05/2010 04:32 PM, Bill Nottingham wrote: > Ralf Corsepius (rc040...@freenet.de) said: > >>> Some languages are distributed for x86_64 with both variant >>> e.g. tcl, because some libraries doesn't work with x86_64 >>> interpreter. We didn't ship perl-5.8.8 for both archs and I don't >>> know about any reason why it changed. >>> > We certainly did ship earlier perl for both arches; check the F7-F12 > releases. (Have't checked earlier, but it's been there forever.) > I checked F11 through rawhide. They all ship perl-*.i?86.rpm. >>> I file a ticket for rel-eng: https://fedorahosted.org/rel-eng/ticket/3695 >>> >> OK, I realize this ticked was closed immediately. >> > It stems from the attached. It may not make sense now that libperl is > separate; at the time, it wasn't. > F11 through rawhide all ship a separate perl-libs. OK, shipping libperl.so makes some limited sense. One use case would be indirect dependency of other (non-perl) i?86-libraries, Nevertheless, I am having difficulties to image how shipping perl-*.i?86.rpm (the base package) makes sense and or how these may even be used on x86_64. May-be the reason is the perl-libs package "Requires" perl because of the /usr/lib/perl5//i386-linux-thread-multi directory's ownership (Provided by the "perl")? The appropriate fix to this would be to let perl-libs own this directory. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Why perl-*.i686.rpm on x86_64?
On 05/04/2010 09:01 AM, Marcela Mašláňová wrote: > On 05/04/2010 07:53 AM, Ralf Corsepius wrote: >> Hi, >> >> Could somebody provide some insight why Fedora ships a >> perl-*i686.rpm package for x86_64? >> >> I don't understand this. My feel is this doesn't make sense and actually >> is a distro composition bug. >> >> Ralf >> -- >> Fedora Extras Perl SIG >> http://www.fedoraproject.org/wiki/Extras/SIGs/Perl >> perl-devel mailing list >> perl-devel@lists.fedoraproject.org >> https://admin.fedoraproject.org/mailman/listinfo/perl-devel >> > Some languages are distributed for x86_64 with both variant > e.g. tcl, because some libraries doesn't work with x86_64 > interpreter. We didn't ship perl-5.8.8 for both archs and I don't > know about any reason why it changed. > I file a ticket for rel-eng: https://fedorahosted.org/rel-eng/ticket/3695 OK, I realize this ticked was closed immediately. @notting: This package is of no use and doesn't make any sense. Please elaborate why you insist of keeping it. Please provide any use-case. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Why perl-*.i686.rpm on x86_64?
On 05/04/2010 09:01 AM, Marcela Mašláňová wrote: > On 05/04/2010 07:53 AM, Ralf Corsepius wrote: >> Hi, >> >> Could somebody provide some insight why Fedora ships a >> perl-*i686.rpm package for x86_64? >> >> I don't understand this. My feel is this doesn't make sense and actually >> is a distro composition bug. > Some languages are distributed for x86_64 with both variant > e.g. tcl, because some libraries doesn't work with x86_64 > interpreter. Well, this makes sense in case of libraries/modules, but how is this be supposed to work in case of perl? I am well aware perl has multiarch/multilib issues, so theoretically, supplying i?86 perl and perl-module could have some use cases, however it's escaping me how this may work with the current packaging: - The applications (/usr/bin/*) of the x86_64 and i686 packages are identical, so one will override the other. - The i686-perl modules all are missing. > We didn't ship perl-5.8.8 for both archs and I don't > know about any reason why it changed. That's what I thought, also. I was surprized to discover otherwise in FC11, FC12, FC13 and rawhide ;) Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Why perl-*.i686.rpm on x86_64?
Hi, Could somebody provide some insight why Fedora ships a perl-*i686.rpm package for x86_64? I don't understand this. My feel is this doesn't make sense and actually is a distro composition bug. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: update of perl-Tk to development release
On 02/18/2010 07:41 PM, Andreas Bierfert wrote: > On Thu, 2010-02-18 at 03:59 -0500, Marcela Maslanova wrote: >> Hello, >> I was wondering if it's worth trying update to development release >> http://search.cpan.org/CPAN/authors/id/S/SR/SREZIC/Tk-804.028_502.tar.gz >> or if you prefer pick interesting patches? The thing is we have three >> years old version. >> Best regards, > > Hi there, > > you are correct the version in fedora is quite old. However, perl-Tk was > a slow moving target as long as I know about it. If we were to upgrade > to the beta it would only be for F-14 rawhide and only in case a release > date would be anticipated withing the F14 time-frame. > > The only exception I can imagine right know is that the development > release fixes/improves upon something major which is broken atm... Agreed, but the real problem with adding "devel-versions packages" to Fedora is them introducing "unstable" (likely temporary) ABI/APIs, and in case of perl-modules, is them also not being unlikely to add perl version-numbering and CPAN issues. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: update of perl-Tk to development release
On 02/18/2010 09:59 AM, Marcela Maslanova wrote: > Hello, > I was wondering if it's worth trying update to development release > http://search.cpan.org/CPAN/authors/id/S/SR/SREZIC/Tk-804.028_502.tar.gz > or if you prefer pick interesting patches? I am very opposed to doing this. Let's stay with officially stable releases until upstream releases a new stable release. > The thing is we have three years old version. And where is the problem? If there are bugs in the stable release, fix them (without breaking ABIs and APIs) or let upstream release a new package. If things are too unstable, remove the package from Fedora. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: why is Padre dependent on Win32::API on Fedora ? [was Re: Broken dependencies: perl-Padre]
On 02/08/2010 06:10 PM, Gabor Szabo wrote: > Hi, > > I saw these bug reports starting to flow in two days ago, > just in time to mention them during my talk on FOSDEM. > > The problem seems to be that the rpm builder extracted the list of > dependencies of Padre from its source code. This did not notice that > Win32::API is use only when running on Windows and thus it was > included in the list of dependencies. > > The right way would be to use the list of dependencies as supplied in > the META.yml file in the Padre tarbal. > > Dave Cross blogged about this probably explaining in a much better way > than I did: > http://perlhacks.com/2010/02/building-rpms-from-cpan-distributions.php Though I partially agree with Dave on his "rpm does something brain-dead" statement, I think his reasoning suffers from a thinko: And that's, of course, where the RPM builders should be going to get a list of dependencies. META.yml contains the list of other modules that the author wants the module to depend on. This should be seen as the definitive list. Of course, there might be errors in that list - but that should be addressed by raising a bug against the module. IMO, he misses that what a perl-module's author thinks he wants "his module to depend on" is largely irrelevant to Fedora. What is relevant to Fedora, is "what the module actually uses" and what we _want_ it to actually use. These sets overlap, but ... they are not identical. Example: Putting bugs in Meta.yml aside (they are not so uncommon as people might believe), a classical corner-case in rpm-packaging perl-modules are "Perl required'ed modules" (i.e. optional modules). To us, they often are not optional, but mandatory (rpm's "Requires:"), because rpm doesn't have a concept of "optional requires". Finally: I question your claim of "META.yml" to be always right. Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: perl's ABRT bug reports
On 02/01/2010 08:03 AM, Marcela Maslanova wrote: > All who may be concerned about a lot of ABRT (automatic bug reporting tool) > bugs: > Since F-13 will be bugs assigned to an application and not to the perl > interpreter. Well, this only would make sense in cases, when scripts triggering a segfault and all script (sub-) modules being used are part of the distro. However, due to the nature of interpreters, in many cases, such scripts are not part of the distro. How do the ABRT authors intend to handle this for other interpreted languages, such as sh, python or tcl? > The another question is whether these segfaults are helpful. Well, ABRT reports like e.g. this one: https://bugzilla.redhat.com/show_bug.cgi?id=560421 are not useful. [As I read this BZ, a user's perl script triggered a segfault in perl and ABRT sent a BZ against perl.] > If anyone has any ideas how could be abrt reports improved for > perl bug reports, do not hesitate to contact guys from upstream project. > https://fedorahosted.org/abrt/ Well, this "plea for help" to me is yet another indication that ABRT has been prematurely made part of the distro. I feel it's not ready, nor do I feel the concepts behind it have proven they work. My recommendation to users: yum remove abrt Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: new priv/vendorlib violating the FHS?
On 01/24/2010 12:39 AM, Chris Weyl wrote: > Hmm. So, privlib/vendorlib in rawhide are now /usr/share/perl5, which > seems to violate the FHS's requirement that /usr/share be used only > for architecture-independent _data_ files[1], with /usr/lib* being > used for libraries.[2] > > Is this a concern, or am I off-base here? No, you're right. /usr/share is supposed to only contain architecture-independent data. Applications, libraries etc. do not belong in there. => vendorlib == /usr/share/perl5 is at least discussworthy. However, I am now wondering about vendorlib's definition and its potential use-cases - Are there any (legitimate) use-cases where something would install arch-dependent data into vendorlib? If the answer to this question is no, then I don't see anything wrong with "vendorlib == /usr/share/perl5". Ralf -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
