[Bug 456019] New: Can we have libpTk.a built shared within 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 report.
https://bugzilla.redhat.com/show_bug.cgi?id=456019
Summary: Can we have libpTk.a built shared within perl-Tk ?
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-Tk
AssignedTo: andreas.bierfert(a)lowlatency.de
ReportedBy: kwizart(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem: libpTk.a is built statically within perl-Tk package.
This file isn't provided, so any dependency that what to extend the widget for
perl-Tk will need to build again this static library.
I would be better to have a shared built instead (if doable)
Version-Release number of selected component (if applicable): current perl-Tk
How reproducible:
always
Steps to Reproduce:
1. built a perl-Tk dependency that extend the widget capability
(case study perl-Tk-TableMatrix, see #444745)
2. by default it will build the libpTk.a again
3. Each Shared Objet widget will pick from libpTk.a as needed, raising the size
of the resulting .so (if not having duplicate code).
Actual results:
-llibpTk is using libpTk.a
Expected results:
-llibpTk should use libpTk.so
Additional info:
The related licenses files should probably be added to the package.
--
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, or are watching someone who is.
14 years, 4 months
[Bug 247476] New: Changed upstream...
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=247476
Summary: Changed upstream...
Product: Fedora
Version: f7
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-Mail-SPF-Query
AssignedTo: steve(a)silug.org
ReportedBy: lmb(a)biosci.ki.se
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Shouldn't this package be updated/replaced with perl-Mail-SPF 2.005??
Note the missing query in the name.
Version-Release number of selected component (if applicable):
1.999.1-3.fc7
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
14 years, 4 months
[Bug 237421] New: Bad cpuTime retrieved from Sys::Virt::Domain->get_info
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=237421
Summary: Bad cpuTime retrieved from Sys::Virt::Domain->get_info
Product: Fedora Extras
Version: fc6
Platform: i686
OS/Version: Linux
Status: NEW
Severity: medium
Priority: medium
Component: perl-Sys-Virt
AssignedTo: steve(a)silug.org
ReportedBy: g+fedora(a)pkg.fr
QAContact: extras-qa(a)fedoraproject.org
CC: berrange@redhat.com,fedora-perl-devel-list(a)redhat.com
Description of problem:
I tried the API on a AMD Athlon(tm) XP 3000+, I got bad values with some
negative one for the cpuTime of a domain.
Version-Release number of selected component (if applicable):
perl-Sys-Virt-0.1.1
How reproducible:
every time
Steps to Reproduce:
1. Run a server with some xen domains
2. Try the example included in the package:
/usr/share/doc/perl-Sys-Virt-0.1.1/examples/dump-info.pl
3. Observe the "cpuTime" values
Actual results:
False
Expected results:
Good
Additional info:
I search the sources and I found this value is in fact unsigned long long value
in libvirt library to represent nanoseconds (cf
http://libvirt.org/html/libvirt-libvirt.html#virDomainInfo). I didn't try on a
64 bits arch but I think the it could work on it.
I managed to obtain the expected results by patching the sources: I edit Virt.xs
from the source and changed the line 359 from:
hv_store (RETVAL, "cpuTime", 7, newSViv(info.cpuTime), 0);
to
hv_store (RETVAL, "cpuTime", 7, newSVnv(info.cpuTime), 0);
So the unsigned long long is read as a float scalar and not an integer scalar.
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
14 years, 4 months
[Bug 199736] New: perl C compiler Can't locate object method "IVX" via package "B::NV"
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199736
Summary: perl C compiler Can't locate object method "IVX" via
package "B::NV"
Product: Fedora Core
Version: fc5
Platform: i386
OS/Version: Linux
Status: NEW
Severity: normal
Priority: normal
Component: perl
AssignedTo: jvdias(a)redhat.com
ReportedBy: timliim(a)lucent.com
QAContact: dkl(a)redhat.com
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
When compile perl script into C code, modules complained
Can't locate object method "IVX" via package "B::NV"
Version-Release number of selected component (if applicable):
$ rpm -qf /usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm
perl-5.8.8-5
How reproducible:
always.
Steps to Reproduce:
1. create a file tw.pl with this content:
#!/usr/bin/perl -w
use strict;
package mx;
sub new {}
#sub x { my $m = 5.1; }
1;
2. compile with this line
time perl -MO=C tw.pl > t.c
Actual results:
Got error msg
Can't locate object method "IVX" via package "B::NV" at
/usr/lib/perl5/5.8.8/i386-linux-thread-multi/B/C.pm line 650.
CHECK failed--call queue aborted.
Expected results:
Compiling ok, produce a compilable .c file:
Additional info:
--
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
14 years, 4 months
[Bug 447006] New: BR Test::CPAN::Meta
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/show_bug.cgi?id=447006
Summary: BR Test::CPAN::Meta
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-Module-Install
AssignedTo: steve(a)silug.org
ReportedBy: steve(a)silug.org
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
t/97_meta...........
skipped
all skipped: Test::CPAN::Meta 0.07 not available for testing
--
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, or are watching someone who is.
14 years, 5 months
[Bug 509419] New: perl-Glib Requires a development package: perl(ExtUtils::MakeMaker)
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-Glib Requires a development package: perl(ExtUtils::MakeMaker)
https://bugzilla.redhat.com/show_bug.cgi?id=509419
Summary: perl-Glib Requires a development package:
perl(ExtUtils::MakeMaker)
Product: Fedora
Version: 11
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: perl-Glib
AssignedTo: tcallawa(a)redhat.com
ReportedBy: kwizart(a)gmail.com
QAContact: extras-qa(a)fedoraproject.org
CC: tcallawa(a)redhat.com, fedora-perl-devel-list(a)redhat.com
Classification: Fedora
Description of problem:
perl-Glib Requires a development package: perl(ExtUtils::MakeMaker)
Version-Release number of selected component (if applicable):
perl-Glib-1.201-2.fc11.i586
How reproducible:
always
Actual results:
There is a need to sort out suches dependencies, specially as this last brings
much other ones , including perl-devel and others perl-Test-* tools.
--
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.
14 years, 6 months
[Bug 502402] New: RFE: please deliver (and use!) filtering macros
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: please deliver (and use!) filtering macros
https://bugzilla.redhat.com/show_bug.cgi?id=502402
Summary: RFE: please deliver (and use!) filtering macros
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: perl
AssignedTo: mmaslano(a)redhat.com
ReportedBy: cweyl(a)alumni.drew.edu
QAContact: extras-qa(a)fedoraproject.org
CC: skasal(a)redhat.com, tcallawa(a)redhat.com,
rc040203(a)freenet.de,
fedora-perl-devel-list(a)redhat.com,
mmaslano(a)redhat.com, lkundrak(a)v3.sk
Classification: Fedora
Created an attachment (id=345264)
--> (https://bugzilla.redhat.com/attachment.cgi?id=345264)
spec patch
arch-specific perl-* packages often have library provides picked up and exposed
vi rpm's autoprov system, where it shouldn't; that is, these provides are
useless, not in the system lib path, and will never be used for proper perl
dependency resolution. e.g. perl-YAML-Syck.i386 provides Syck.so(), mod_perl
provides a slew of them, etc.
These macros will allow us to sensibly filter useless provides out:
http://fedorapeople.org/~cweyl/macros.perl
The core perl package should deliver /etc/rpm/macros.perl, as above, and employ
them to clean up its errant provides. I've attached a patch that does that, as
well as the additional %SOURCEs needed; a scratch build of the modifications
has been run.
http://koji.fedoraproject.org/koji/taskinfo?taskID=1375064
Thanks! :)
--
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.
14 years, 6 months
[Bug 502403] New: RFE: add %{?perl_default_filter} to the perl spec template
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: add %{?perl_default_filter} to the perl spec template
https://bugzilla.redhat.com/show_bug.cgi?id=502403
Summary: RFE: add %{?perl_default_filter} to the perl spec
template
Product: Fedora
Version: rawhide
Platform: All
OS/Version: Linux
Status: NEW
Severity: medium
Priority: low
Component: rpmdevtools
AssignedTo: ville.skytta(a)iki.fi
ReportedBy: cweyl(a)alumni.drew.edu
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com, ville.skytta(a)iki.fi
Classification: Fedora
arch-specific perl-* packages often have library provides picked up and exposed
vi rpm's autoprov system, where it shouldn't; that is, these provides are
useless, not in the system lib path, and will never be used for proper perl
dependency resolution. e.g. perl-YAML-Syck.i386 provides Syck.so(), mod_perl
provides a slew of them, etc.
We're working on bundling a set of new macros with the perl package; these
macros will allow us to sensibly filter useless provides out.
http://fedorapeople.org/~cweyl/macros.perl
Please update the perl spec template to conditionally invoke the default perl
filtering macro, by inserting "%{?perl_default_filter} before %description.
Thanks!
--
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.
14 years, 6 months