[Bug 1122498] New: Missing perl-Time-HiRes requirement
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1122498
Bug ID: 1122498
Summary: Missing perl-Time-HiRes requirement
Product: Fedora
Version: rawhide
Component: perl
Keywords: EasyFix, Patch
Assignee: jplesnik(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: cweyl(a)alumni.drew.edu, iarnell(a)gmail.com,
jplesnik(a)redhat.com, kasal(a)ucw.cz,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tcallawa(a)redhat.com
+++ This bug was initially created as a clone of Bug #1122368 +++
perl-Time-HiRes seems to be a missing requirement when configuring cpan for the
first time.
See https://bugs.centos.org/view.php?id=7417 for the details and reproduction
steps.
[...]
--- Additional comment from Petr Pisar on 2014-07-23 09:08:54 GMT ---
This is a bug in `perl' package. The package should run-require
`perl(Time::HiRes)' because Net::Ping module's hires() subroutine loads
Time::HiRes:
$hires = 0;
sub hires
{
my $self = shift;
$hires = 1 unless defined
($hires = ((defined $self) && (ref $self)) ? shift() : $self);
require Time::HiRes if $hires;
}
--- Additional comment from Petr Pisar on 2014-07-23 09:38:27 GMT ---
There is another issue after proceeding next:
Can't locate local/lib.pm in @INC (@INC contains:
/root/perl5/lib/perl5/x86_64-linux-thread-multi /root/perl5/lib/perl5
/usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 /root) at
/usr/share/perl5/CPAN/FirstTime.pm line 1300.
The CPAN::FirstTime module offers local::lib by default if site directories do
not exist:
sub _local_lib_config {
# Set environment stuff for this process
require local::lib;
[...]
}
perl-CPAN sub-package should run-require `perl(local::lib)' too.
--- Additional comment from Petr Pisar on 2014-07-23 09:47:12 GMT ---
How to test:
(1) # yum remove perl
(2) # yum install /usr/bin/cpan
(3) # rm -rf ~/.cpan
(4) # cpan </dev/null
Before:
The reported message is printed and the `cpan' command dies with a non-zero
exit code.
After:
The `cpan' command succeeds.
----
Distribution perl(Time::HiRes) perl(local::lib)
Fedora 22 ok missing
Fedora 21 ok missing
Fedora 20 ok missing
Fedora 19 ok missing
--
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=Wy6E4PqhYT&a=cc_unsubscribe
7Â years, 11Â months
[Bug 1110326] New: perl-Time-Mock-0.0.2-5.fc21 FTBFS on heavily loaded machine
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1110326
Bug ID: 1110326
Summary: perl-Time-Mock-0.0.2-5.fc21 FTBFS on heavily loaded
machine
Product: Fedora
Version: rawhide
Component: perl-Time-Mock
Assignee: yaneti(a)declera.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org, yaneti(a)declera.com
perl-Time-Mock-0.0.2-5.fc21 fails to build if the host is heavily loaded. Then
some test sensitive to elapsed time will not pass:
# Failed test at t/import.t line 17.
# '1402724184'
# <=
# '1402724180'
# Looks like you failed 1 test of 7.
t/import.t ...
Dubious, test returned 1 (wstat 256, 0x100)
Failed
This is causes by this code:
my $start = time;
cmp_ok($start, '>=', $otime + 10_000);
sleep(1);
my $end = time;
cmp_ok($end, '>=', $start + 1);
cmp_ok($end, '<=', $start + 2);
The last cmp_ok() test will fail if the running time is more then 2 throttled
seconds (2/100 real seconds).
--
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=aU5DdEmpOZ&a=cc_unsubscribe
7Â years, 11Â months
[Bug 1110292] New: perl-Text-Xslate-3.1.2-3.fc21 FTBFS under heavy load:
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1110292
Bug ID: 1110292
Summary: perl-Text-Xslate-3.1.2-3.fc21 FTBFS under heavy load:
Product: Fedora
Version: rawhide
Component: perl-Text-Xslate
Assignee: i(a)cicku.me
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: i(a)cicku.me, perl-devel(a)lists.fedoraproject.org
perl-Text-Xslate-3.1.2-3.fc21 fails to build if the host is heavily loaded
because t/010_internals/008_files.t test fails:
# Failed test 'auto reload 1'
# at t/010_internals/008_files.t line 81.
# got: 'Hello, Perl world!
# '
# expected: 'Hi, Perl.
# '
# Failed test 'auto reload 2'
# at t/010_internals/008_files.t line 81.
# got: 'Hello, Perl world!
# '
# expected: 'Hi, Perl.
# '
# Looks like you failed 2 tests of 67.
t/010_internals/008_files.t .....................
Dubious, test returned 2 (wstat 512, 0x200)
Failed
This looks like a race in the tests. The test does:
utime $^T+10, $^T+10, $x;
is $tx->render('hello.tx', { lang => 'Perl' }),
"Hi, Perl.\n", "auto reload $_" for 1 .. 2;
If you comment the utime call out, it will fail always.
--
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=61ozxbsmMW&a=cc_unsubscribe
7Â years, 11Â months
[Bug 1003471] New: Manual pages generated from POD have almost all Unicode characters mangled to X
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1003471
Bug ID: 1003471
Summary: Manual pages generated from POD have almost all
Unicode characters mangled to X
Product: Fedora
Version: rawhide
Component: perl-podlators
Assignee: ppisar(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com
$ cat test
=encoding utf8
=head1 Kroužkovci
ŽÃžala
=cut
$ pod2man test |tail
.\"
.IX Title "TEST 1"
.TH TEST 1 "2013-09-02" "perl v5.18.1" "User Contributed Perl Documentation"
.\" For nroff, turn off justification. Always turn off hyphenation; it makes
.\" way too many mistakes in technical documents.
.if n .ad l
.nh
.SH "KrouXkovci"
.IX Header "KrouXkovci"
Xi\*'Xala
This is caused by upstream decision to have pod2man output compatible with all
ROFFs. That means to pass ASCII charachtes, escape ISO-8859-1 characters, and
to replace others with plain `X'
(<https://rt.cpan.org/Public/Bug/Display.html?id=68741>).
There is pod2man option --utf8 which disables any escaping and outputs UTF-8,
but this is not default behaviour. This makes all manual pages from built
packages to be mangled. See Debian bug report
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480997>.
Question is what to do. Should we be faster than upstream and make UTF-8 output
default? Should defaults you locale encoding? (Fedora packages are built in C
locale.)
--
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=1dZWcp091d&a=cc_unsubscribe
7Â years, 11Â months
[Bug 981243] New: SDLx::App->new() does not work on frame buffer console
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=981243
Bug ID: 981243
Summary: SDLx::App->new() does not work on frame buffer console
Product: Fedora
Version: 18
Component: perl-SDL
Severity: unspecified
Priority: unspecified
Assignee: hdegoede(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: hdegoede(a)redhat.com,
perl-devel(a)lists.fedoraproject.org
Created attachment 768694
--> https://bugzilla.redhat.com/attachment.cgi?id=768694&action=edit
Reproducer
I'm not able to initialize SDL video on frame buffer console using high-level
SDLx::App->new(). But it works with low-level SDL::Video::set_video_mode().
Output from the reproducer:
# DISPLAY= perl test -width 1280 -height 1024 -depth 32
Testing plain SDL:
Plain SDL::Video::set_video_mode() is Ok.
Width is 1280
Testing plain SDL::App:
Couldn't set console screen info at /usr/lib64/perl5/vendor_perl/SDLx/App.pm
line 123.
SDLx::App::new('SDLx::App', '-width', 1280, '-height', 1024, '-depth',
32) called at test line 32
root@dhcp-0-146:/tmp # rpm -q perl-SDL
perl-SDL-2.540-2.fc18.x86_64
--
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=GviunhawfM&a=cc_unsubscribe
7Â years, 11Â months
[Bug 1121638] New: perl-Crypt-DES not built for EPEL7 (required by perl-Net-SNMP)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1121638
Bug ID: 1121638
Summary: perl-Crypt-DES not built for EPEL7 (required by
perl-Net-SNMP)
Product: Fedora EPEL
Version: epel7
Component: perl-Crypt-DES
Severity: high
Assignee: steve(a)silug.org
Reporter: haldir.junk(a)gmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: perl-devel(a)lists.fedoraproject.org,
psabata(a)redhat.com, steve(a)silug.org
Description of problem:
perl-Net-SNMP requires perl-Crypt-DES but this package has not yet been built
for EPEL7.
Version-Release number of selected component (if applicable):
How reproducible:
Attempt to install perl-Net-SNMP and/or perl-Crypt-DES
Steps to Reproduce:
1.
2.
3.
Actual results:
Error: Package: perl-Net-SNMP-6.0.1-7.el7.noarch (epel)
Requires: perl(Crypt::DES)
Expected results:
Successful installation
Additional info:
--
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=lvpjmIACC8&a=cc_unsubscribe
7Â years, 11Â months
[Bug 1300870] New: fusioninventory-agent-2.3.18-rc1 is available
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1300870
Bug ID: 1300870
Summary: fusioninventory-agent-2.3.18-rc1 is available
Product: Fedora
Version: rawhide
Component: fusioninventory-agent
Keywords: FutureFeature, Triaged
Assignee: marianne(a)tuxette.fr
Reporter: upstream-release-monitoring(a)fedoraproject.org
QA Contact: extras-qa(a)fedoraproject.org
CC: marianne(a)tuxette.fr,
perl-devel(a)lists.fedoraproject.org
Latest upstream release: 2.3.18-rc1
Current version/release in rawhide: 2.3.17-1.fc24
URL: http://www.fusioninventory.org/
Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring
Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 11Â months