[Bug 783346] New: Perl-MIME-Lite is already in RHEL6
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-MIME-Lite is already in RHEL6
https://bugzilla.redhat.com/show_bug.cgi?id=783346
Summary: Perl-MIME-Lite is already in RHEL6
Product: Fedora EPEL
Version: el6
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: perl-MIME-Lite
AssignedTo: steve.traylen(a)cern.ch
ReportedBy: bochecha(a)fedoraproject.org
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com,
mmcgrath(a)redhat.com, steve.traylen(a)cern.ch
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
This package is already in RHEL6, as such, shouldn't it be dropped from EPEL6?
# yum whatprovides 'perl(MIME::Lite)'
Loaded plugins: changelog, merge-conf, rhnplugin
perl-MIME-Lite-3.027-2.el6.noarch : MIME::Lite - low-calorie MIME generator
Repo : epel
Matched from:
Other : perl(MIME::Lite)
perl-MIME-Lite-3.027-2.el6.noarch : MIME::Lite - low-calorie MIME generator
Repo : rhel-x86_64-server-optional-6
Matched from:
Other : perl(MIME::Lite)
--
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.
8 years, 5 months
[Bug 1062576] New: memory leak when including a file with "use utf8"
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1062576
Bug ID: 1062576
Summary: memory leak when including a file with "use utf8"
Product: Fedora
Version: 19
Component: perl
Severity: medium
Assignee: jplesnik(a)redhat.com
Reporter: lav(a)yars.free.net
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
Description of problem:
Every time perl includes a file with "use utf8" and text constants it leaks
memory.
Version-Release number of selected component (if applicable):
perl-5.16.3-266.fc19.x86_64
How reproducible:
always
Steps to Reproduce:
1. run the test program below
2. watch as memory usage grows
Here is the test program:
-------------------------
my $mem = 0;
sub report_memory () {
my $next_mem = qx[ps -p $$ -o size=]+0;
printf "%+8d = %8d K\n", $next_mem-$mem, $next_mem; $mem = $next_mem;
}
for (0..1e5) {
do 'x.inc';
report_memory unless $_ % 1e4;
}
-------------------------
x.inc contains:
-------------------------
use utf8;
$x='x';
-------------------------
--
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=l7ghbj1UQE&a=cc_unsubscribe
8 years, 6 months
[Bug 839612] New: FTBFS perl-Unix-Statgrab-0.04-14.fc18
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=839612
Bug ID: 839612
QA Contact: extras-qa(a)fedoraproject.org
Severity: unspecified
URL: https://koji.fedoraproject.org/koji/taskinfo?taskID=42
36283
Version: rawhide
Priority: unspecified
CC: oliver(a)linux-kernel.at,
perl-devel(a)lists.fedoraproject.org, steve(a)silug.org
Assignee: steve(a)silug.org
Summary: FTBFS perl-Unix-Statgrab-0.04-14.fc18
Regression: ---
Story Points: ---
Classification: Fedora
OS: Unspecified
Reporter: ppisar(a)redhat.com
Type: Bug
Documentation: ---
Hardware: Unspecified
Mount Type: ---
Status: NEW
Component: perl-Unix-Statgrab
Product: Fedora
perl-Unix-Statgrab-0.04-14.fc18 does not build in F18:
Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.FI62R4
+ umask 022
+ cd /builddir/build/BUILD
+ cd Unix-Statgrab-0.04
+ unset DISPLAY
+ make test
PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/0_pod.t ........... ok
t/0_pod_coverage.t .. ok
t/Unix-Statgrab.t ...
Failed 1/22 subtests
Test Summary Report
-------------------
t/Unix-Statgrab.t (Wstat: 11 Tests: 21 Failed: 0)
Non-zero wait status: 11
Parse errors: Bad plan. You planned 22 tests but ran 21.
Files=3, Tests=23, 0 wallclock secs ( 0.04 usr 0.00 sys + 0.15 cusr 0.03
csys = 0.22 CPU)
Result: FAIL
Failed 1/3 test programs. 0/23 subtests failed.
make: *** [test_dynamic] Error 255
This happens with perl 5.16.0. I guess the test plan is wrong or the perl
segfaults.
--
You are receiving this mail because:
You are on the CC list for the bug.
8 years, 7 months
[Bug 750805] New: Fails to build on ARM, needs to use default setjmp not ucontext
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: Fails to build on ARM, needs to use default setjmp not ucontext
https://bugzilla.redhat.com/show_bug.cgi?id=750805
Summary: Fails to build on ARM, needs to use default setjmp not
ucontext
Product: Fedora
Version: 15
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: perl-Coro
AssignedTo: ppisar(a)redhat.com
ReportedBy: henrik(a)henriknordstrom.net
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com,
mmaslano(a)redhat.com, kwizart(a)gmail.com,
bochecha(a)fedoraproject.org, ppisar(a)redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Description of problem:
ARM do not implement the needed ucontext functions, and need to use the default
setjmp method. This is normally the default, except that fedora patches it to
hardwire ucontext as default method..
Version-Release number of selected component (if applicable):
perl-Coro-5.372-3.fc15
How reproducible:
always
Steps to Reproduce:
1. Try to rebuild perl-Coro on arm
2.
3.
Actual results:
failed build, crashing in testsuite
Expected results:
successful build
Additional info:
Trivial spec file patch attached.
Please apply patch and sumbit a F15 koji build from which arm can pull the
srpm. update request is not stricty needed if the only change relative to
current F15 build is this 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.
8 years, 9 months
[Bug 1068706] New: Password prompt matching requires colon, which may be missing
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1068706
Bug ID: 1068706
Summary: Password prompt matching requires colon, which may be
missing
Product: Fedora
Version: 20
Component: perl-Net-SFTP-Foreign
Severity: low
Assignee: fedorapkg(a)rule.lv
Reporter: ejtr(a)layer3.co.uk
QA Contact: extras-qa(a)fedoraproject.org
CC: fedorapkg(a)rule.lv, perl-devel(a)lists.fedoraproject.org
Description of problem:
Net::SFTP::Foreign's password prompt matching code goes into a permanent loop
when the remote server supplies a prompt without a trailing colon.
Version-Release number of selected component (if applicable):
perl-Net-SFTP-Foreign-1.75-3.fc20.noarch.rpm
How reproducible:
When testing Net::SFTP::Foreign against an "unusual" host which supported
keyboard-interactive authentication, and thus generated a server-supplied
password prompt, it was found that the host in question had a prompt of the
form "username's password", rather than the more usual "username@host's
password: " as seen from OpenSSH client code supporting the password
authentication mode.
As a consequence, the Net::SFTP::Foreign module simply sulked waiting for a
colon.
Looking at the relevant
/usr/share/perl5/vendor_perl/Net/SFTP/Foreign/Backend/Unix.pm code file, we
find the following code fragment:
.....
debug and $debug & 65536 and _debug "looking for user/password prompt";
my $re = ( defined $password_prompt
? $password_prompt
: qr/(user|name|login)?[:?]\s*$/i );
$debug and $debug & 65536 and _debug "matching against $re";
if (substr($buffer, $at) =~ $re) {
if ($ask_for_username_at_login and
($ask_for_username_at_login ne 'auto' or defined $1)) {
$debug and $debug & 65536 and _debug "sending username";
print $pty "$user\n";
undef $ask_for_username_at_login;
}
else {
$debug and $debug & 65536 and _debug "sending password";
print $pty "$pass\n";
$password_sent = 1;
}
$at = length $buffer;
}
.....
In the absence of the $password_prompt setting, $re only matches a password
prompt containing the string "password" if it contains a colon or question-mark
after the word "password".
The code is also questionable in being capable of sending a password in
response to a prompt which contains only a colon followed by whitespace; I feel
it ought to at least see the word "password" or "passphrase".
The code also uses the $password_prompt variable to match against a potential
username prompt, which is questionable.
I believe it would be better to more completely separate the user and password
prompt matching with different Regex's, and avoid being able to match against
the short ":" string alone, and cope with the unusual condition of a missing
colon.
This recoding of the relevant block is a potential solution:
.....
$debug and $debug & 65536 and _debug "looking for user/password prompt";
my $reuser = qr/(user|name|login)([:?])?\s*$/i;
my $repass = ( defined $password_prompt ?
$password_prompt : qr/(password|passphrase)([:?])?\s*$/i );
if (substr($buffer, $at) =~ $reuser) {
$debug and $debug & 65536 and _debug "matched against $reuser";
if ($ask_for_username_at_login and
($ask_for_username_at_login ne 'auto' or defined $1)) {
$debug and $debug & 65536 and _debug "sending username";
print $pty "$user\n";
undef $ask_for_username_at_login;
}
$at = length $buffer;
} elsif (substr($buffer, $at) =~ $repass) {
$debug and $debug & 65536 and _debug "matched against $repass";
$debug and $debug & 65536 and _debug "sending password";
print $pty "$pass\n";
$password_sent = 1;
$at = length $buffer;
}
....
--
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=SXtN9EENTL&a=cc_unsubscribe
8 years, 10 months
[Bug 1085704] New: tests failing on big endians
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1085704
Bug ID: 1085704
Summary: tests failing on big endians
Product: Fedora
Version: 20
Component: slic3r
Assignee: mhroncok(a)redhat.com
Reporter: dan(a)danny.cz
QA Contact: extras-qa(a)fedoraproject.org
CC: mhroncok(a)redhat.com,
perl-devel(a)lists.fedoraproject.org
Blocks: 467765 (ZedoraTracker), 1071880 (PPCTracker)
A test is failing in big endian arches like s390(x) and ppc/ppc64
from build.log:
...
+ cd -
/builddir/build/BUILD/Slic3r-1.0.0
+ SLIC3R_NO_AUTO=1
+ perl Build.PL installdirs=vendor
t/angles.t ........... ok
t/arcs.t ............. skipped: arcs are currently disabled
t/clean_polylines.t .. ok
t/clipper.t .......... ok
t/collinear.t ........ ok
t/combineinfill.t .... ok
t/cooling.t .......... ok
t/custom_gcode.t ..... ok
t/dynamic.t .......... skipped: variable-width paths are currently disabled
# Failed test 'no missing parts in solid shell when fill_density is 0'
# at t/fill.t line 252.
# got: '12'
# expected: '0'
# Looks like you failed 1 test of 42.
t/fill.t .............
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/42 subtests
t/gcode.t ............ ok
t/geometry.t ......... ok
t/layers.t ........... ok
t/loops.t ............ skipped: temporarily disabled
t/multi.t ............ ok
t/perimeters.t ....... ok
t/polyclip.t ......... ok
t/print.t ............ ok
t/retraction.t ....... ok
t/shells.t ........... ok
t/skirt_brim.t ....... ok
t/slice.t ............ skipped: temporarily disabled
t/support.t .......... ok
t/svg.t .............. ok
t/thin.t ............. ok
t/threads.t .......... ok
t/vibrationlimit.t ... ok
Test Summary Report
-------------------
t/fill.t (Wstat: 256 Tests: 42 Failed: 1)
Failed test: 42
Non-zero exit status: 1
Files=27, Tests=241, 55 wallclock secs ( 0.09 usr 0.03 sys + 55.73 cusr 0.67
csys = 56.52 CPU)
Result: FAIL
Some tests failed. Please report the failure to the author!
error: Bad exit status from /var/tmp/rpm-tmp.4roGD8 (%check)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.4roGD8 (%check)
Child return code was: 1
for full logs please see
http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1374201
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1767561
Version-Release number of selected component (if applicable):
slic3r-1.0.0-0.3.RC2.fc21 is OK
slic3r-1.0.0-0.4.RC3.fc21 is BROKEN, newer are broken too
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=467765
[Bug 467765] Fedora for System z (s390): Bug Tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1071880
[Bug 1071880] (PPCTracker) Fedora for PowerPC architectures (ppc,ppc64):
Bug Tracker
--
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=9rKa2d72oi&a=cc_unsubscribe
8 years, 10 months
[Bug 1039268] New: png images not displayed
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1039268
Bug ID: 1039268
Summary: png images not displayed
Product: Fedora
Version: 20
Component: perl-Tk
Assignee: andreas.bierfert(a)lowlatency.de
Reporter: eserte12(a)yahoo.de
QA Contact: extras-qa(a)fedoraproject.org
CC: andreas.bierfert(a)lowlatency.de,
perl-devel(a)lists.fedoraproject.org
External Bug ID: CPAN 87016
Description of problem:
png images cannot be displayed anymore using perl-Tk's Tk::PNG module. This is
probably related to https://rt.cpan.org/Public/Bug/Display.html?id=87016
The problem does not appear anymore with a development release of Perl/Tk, e.g.
SREZIC/Tk-804.031_502.tar.gz
Version-Release number of selected component (if applicable):
perl-Tk-804.031-4.fc20.i686
How reproducible:
Steps to Reproduce:
1. Try the following oneliner with a random png image: perl -MTk -MTk::PNG -e
'$mw=tkinit;$mw->Label(-image => $mw->Photo(-file => shift))->pack; MainLoop'
pngtest.png
2.
3.
Actual results:
Error message "invalid after png_start_read_image or png_read_update_info at
/usr/lib/perl5/vendor_perl/Tk/Image.pm line 21.", no png image is displayed
Expected results:
png image should be visible in a X11 window, like it's the case with fedora 19.
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=AqqyR7Q0Bx&a=cc_unsubscribe
8 years, 10 months
[Bug 919030] New: perl-Glib-Object-Introspection seems to have a big-endian problem, self tests fail on s390* and ppc*
by Red Hat Bugzilla
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=919030
Bug ID: 919030
Summary: perl-Glib-Object-Introspection seems to have a
big-endian problem, self tests fail on s390* and ppc*
Product: Fedora
Version: rawhide
Component: perl-Glib-Object-Introspection
Severity: high
Priority: medium
Reporter: karsten(a)redhat.com
Description of problem:
# Failed test at t/00-basic-types.t line 15.
# got: '-1'
# expected: '-127'
# Failed test at t/00-basic-types.t line 16.
# got: '0'
# expected: '255'
# Failed test at t/00-basic-types.t line 17.
# got: '-1'
# expected: '-32767'
# Failed test at t/00-basic-types.t line 18.
# got: '0'
# expected: '65535'
# Looks like you failed 4 tests of 34.
t/00-basic-types.t ............
Dubious, test returned 4 (wstat 1024, 0x400)
Failed 4/34 subtests
# Failed test at t/arg-checks.t line 11.
# got: '-1'
# expected: '-127'
# Failed test at t/arg-checks.t line 21.
# got: '0'
# expected: '127'
# Looks like you failed 2 tests of 5.
t/arg-checks.t ................
Dubious, test returned 2 (wstat 512, 0x200)
Version-Release number of selected component (if applicable):
perl-Glib-Object-Introspection-0.015-1.fc19
How reproducible:
always
Steps to Reproduce:
1. ppc-koji build --scratch f19
perl-Glib-Object-Introspection-0.015-1.fc19.src.rpm
2.
3.
Actual results:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=973021
Expected results:
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=YIO2oILrQB&a=cc_unsubscribe
8 years, 10 months