[Bug 810858] New: RFE: use %perl_bootstrap macro to enable bootstrap dependency filtering
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: RFE: use %perl_bootstrap macro to enable bootstrap dependency filtering
https://bugzilla.redhat.com/show_bug.cgi?id=810858
Summary: RFE: use %perl_bootstrap macro to enable bootstrap
dependency filtering
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: perl-bioperl
AssignedTo: alexl(a)users.sourceforge.net
ReportedBy: paul(a)city-fan.org
QAContact: extras-qa(a)fedoraproject.org
CC: alexl(a)users.sourceforge.net,
fedora-perl-devel-list(a)redhat.com
Classification: Fedora
Story Points: ---
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Created attachment 576201
--> https://bugzilla.redhat.com/attachment.cgi?id=576201
Implement use of %perl_bootstrap
The problem of bootstrapping perl-bioperl and perl-bioperl-run on a new
architecture or perl release is well known and documented in Bug #537138.
It will soon be time to rebuild the perl ecosystem in Rawhide for perl 5.16,
and it would be good to be able to do this "cleanly" as if bootstrapping a new
architecture. The perl-bioperl* packages are not the only ones with circular
build dependencies, and the Perl SIG has been applying a methodology of doing
an initial build with a macro %perl_bootstrap defined so that packages with
circular dependency issues can be built in a way that breaks the cycles, and
then, once the ecosystem has been bootstrapped, those packages using
%perl_bootstrap can be rebuilt again with it undefined so as to create the
packages as their maintainers intended.
To that end, it would be good if you could implement the use of %perl_bootstrap
in perl-bioperl, to replace the commented-out filtering scheme currently in
place. The attached patch does this. There are two versions of the filters, one
for rpm 4.9 or later (F-15 or later) and one for earlier releases. Rather than
using the "rpm 4.8" style for this as currently used in the comments, I've used
perl-specific dependency filtering that would work all the way back to EPEL-5
if the necessary dependencies were there, though I tested it using F-14.
Testing results:
F-14:
$ rpmdiff --ignore T current-build/perl-bioperl-1.6.1-11.fc14.noarch.rpm
new-build/perl-bioperl-1.6.1-11.fc14.noarch.rpm
removed REQUIRES rpmlib(VersionedDependencies) <= 3.0.3-1
$
$ rpmdiff --ignore T current-build/perl-bioperl-1.6.1-11.fc14.noarch.rpm
new-build-boot/perl-bioperl-1.6.1-11.fc14.noarch.rpm
removed REQUIRES perl(Bio::Tools::Run::Alignment::Clustalw)
removed REQUIRES perl(Bio::Tools::Run::GenericParameters)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Molphy::ProtML)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Phylip::Neighbor)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Phylip::ProtDist)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Phylip::ProtPars)
removed REQUIRES perl(Bio::Tools::Run::RemoteBlast)
removed REQUIRES rpmlib(VersionedDependencies) <= 3.0.3-1
$
Rawhide:
$ rpmdiff --ignore T current-build/perl-bioperl-1.6.1-11.fc18.noarch.rpm
new-build/perl-bioperl-1.6.1-11.fc18.noarch.rpm
$
$ rpmdiff --ignore T current-build/perl-bioperl-1.6.1-11.fc18.noarch.rpm
new-build-boot/perl-bioperl-1.6.1-11.fc18.noarch.rpm
removed REQUIRES perl(Bio::Tools::Run::Alignment::Clustalw)
removed REQUIRES perl(Bio::Tools::Run::GenericParameters)
removed REQUIRES perl(Bio::Tools::Run::ParametersI)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Molphy::ProtML)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Phylip::Neighbor)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Phylip::ProtDist)
removed REQUIRES perl(Bio::Tools::Run::Phylo::Phylip::ProtPars)
removed REQUIRES perl(Bio::Tools::Run::RemoteBlast)
removed REQUIRES perl(Bio::Tools::Run::StandAloneBlast)
removed REQUIRES perl(Bio::Tools::Run::WrapperBase)
$
Note that the older rpm in F-14 did not pick up as many perl dependencies as
Rawhide's rpm, hence fewer were filtered for the bootstrap build.
The disappearance of "REQUIRES rpmlib(VersionedDependencies) <= 3.0.3-1" in the
F-14 builds is due to the change from "rpm 4.8" style filtering to the
perl-specific filtering.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Bug 1152319] New: perl-Module-Starter should depend on perl-Software-License
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1152319
Bug ID: 1152319
Summary: perl-Module-Starter should depend on
perl-Software-License
Product: Fedora
Version: 20
Component: perl-Module-Starter
Severity: low
Assignee: ppisar(a)redhat.com
Reporter: rp(a)guests.deus.net
QA Contact: extras-qa(a)fedoraproject.org
CC: mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com
Description of problem:
When used with some fairly simple settings, derived from the examples given in
the documentation, the module-starter tool from perl-Module-Starter produces
code which doesn't work correctly without the Software::License module as found
in perl-Software-License. Worse, it gives misleading error messages and it's
not clear which package the problem is in without tracing through code. So I
think it would be sensible to have perl-Module-Starter require
perl-Software-License, even though it isn't strictly necessary for it to
function.
Version-Release number of selected component (if applicable):
perl-Module-Starter-1.62-1.fc20.noarch
Steps to Reproduce:
With perl-Software-License not installed (and the Software::License module not
available on the system through any other means):
1. module-starter --module=My::Module --builder=Module::Build
--email=example(a)example.com
2. cd My-Module
3. perl Build.PL
Actual results:
Could not get valid metadata. Error is: Invalid metadata structure. Errors:
License 'Artistic_2_0' is invalid (license) [Validation: 1.4]
at /usr/share/perl5/vendor_perl/Module/Build/Base.pm line 4589
Expected results:
No error message, clean build.
Additional info:
http://www.perlmonks.org/?node_id=1006882 shows a user encountering this
problem and not being able to trace it - the suggested fix there is to install
Software::License.
The configuration included in perl-Module-Starter-PBP makes this problem even
easier to encounter, because it makes --builder=Module::Build the default.
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=RE5cu9Be6X&a=cc_unsubscribe
9 years, 3 months
[Bug 628655] New: perl segfaults when joining a thread and using perl-Tk
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: perl segfaults when joining a thread and using perl-Tk
https://bugzilla.redhat.com/show_bug.cgi?id=628655
Summary: perl segfaults when joining a thread and using perl-Tk
Product: Fedora
Version: 13
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-Tk
AssignedTo: andreas.bierfert(a)lowlatency.de
ReportedBy: rdevries1000(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: andreas.bierfert(a)lowlatency.de,
fedora-perl-devel-list(a)redhat.com
Classification: Fedora
Description of problem:
perl segfaults when joining a thread and using perl-Tk
Version-Release number of selected component (if applicable):
perl-5.10.1-116.fc13.x86_64
How reproducible:
Execute the next code:
use strict;
use Tk;
use threads;
sub init {
print "exiting init\n";
}
my $thread1 = threads->create("init");
my $mw = MainWindow->new();
$thread1->join();
print "finished\n";
exit(0);
Steps to Reproduce:
execute the above code by:
perl threadtest.pl
Actual results:
perl ./threadtest.pl
exiting init
finished
Segmentation fault (core dumped)
Exit value of process:
>echo $?
139
Expected results:
perl ./threadtest.pl
exiting init
finished
Exit value of process:
>echo $?
0
Additional info:
using perl-Tk package: perl-Tk-804.028-11.fc13.x86_64
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Bug 708377] New: [PATCH] normalize perl version in build requires
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: [PATCH] normalize perl version in build requires
https://bugzilla.redhat.com/show_bug.cgi?id=708377
Summary: [PATCH] normalize perl version in build requires
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: cpanspec
AssignedTo: steve(a)silug.org
ReportedBy: mmaslano(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: steve(a)silug.org, fedora-perl-devel-list(a)redhat.com
Classification: Fedora
Story Points: ---
cpanspec generate Perl version in non-rpm format eg. 5.60000, but we need
something like 5.6.0. Module version can normalize it. I propose attached
patch.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months
[Bug 544738] New: cpanspec doesn't escape "/" in --filter-requires leading to bad sed statements
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
Summary: cpanspec doesn't escape "/" in --filter-requires leading to bad sed statements
https://bugzilla.redhat.com/show_bug.cgi?id=544738
Summary: cpanspec doesn't escape "/" in --filter-requires
leading to bad sed statements
Product: Fedora
Version: 12
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: cpanspec
AssignedTo: steve(a)silug.org
ReportedBy: bugzilla(a)kosowsky.org
QAContact: extras-qa(a)fedoraproject.org
CC: steve(a)silug.org, fedora-perl-devel-list(a)redhat.com
Classification: Fedora
Description of problem:
cpanspec translates each "--filter-requires some_string" into a corresponding
sed statement in the corresponding perl-<module>-requires.sh of form:
-e '/^some-string$/d'
However, when some_string is a path which then contains a slash "/", this
causes the sed statement to mess up.
In particular, one of the fuse modules I was compiling had some example perl
scripts which began with the line "#/usr/bin/perl." This caused the build to
then require "/usr/bin/perl" which I wanted to eliminate. When I added
"--filter-requires /usr/bin/perl", it caused *all* the sed statements to fail
with the error:
sed: -e expression #1, char 4: unknown command: `u'
Either the documentation should warn that "/" must be escaped or *better*, the
script should automatically escape the forward slashes since the user has no
reason to think that "/" is a special character (and indeed, sed could have
used just about any character to demarcate the s program)
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
9 years, 3 months