[Bug 831716] New: Moving legacy code out of perl-JSON-RPC breaks Bugzilla
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=831716
Bug ID: 831716
QA Contact: extras-qa(a)fedoraproject.org
Severity: high
Version: 17
Priority: unspecified
CC: emmanuel.seyman(a)club-internet.fr,
perl-devel(a)lists.fedoraproject.org
Assignee: emmanuel.seyman(a)club-internet.fr
Summary: Moving legacy code out of perl-JSON-RPC breaks
Bugzilla
Regression: ---
Story Points: ---
Classification: Fedora
OS: Linux
Reporter: lpsolit(a)netscape.net
Type: Bug
Documentation: ---
Hardware: All
Mount Type: ---
Status: NEW
Component: perl-JSON-RPC
Product: Fedora
Bugzilla still uses legacy code from JSON::RPC and despite the perl-JSON-RPC
package is installed, which makes checksetup.pl happy, the JSON-RPC feature of
Bugzilla fails because it cannot find the legacy code. This also prevents
Apache from starting when mod_perl is enabled:
httpd[1938]: Can't locate JSON/RPC/Legacy/Server/CGI.pm in @INC
So the legacy code is still required by Bugzilla, and checksetup.pl and
Bugzilla re confused by this package split.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 4 months
[Bug 1054061] New: Segfault in Perl_gv_fetchpvn_flags when trying to initialize back_perl openldap backend
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1054061
Bug ID: 1054061
Summary: Segfault in Perl_gv_fetchpvn_flags when trying to
initialize back_perl openldap backend
Product: Red Hat Enterprise Linux 7
Version: 7.0
Component: perl
Assignee: perl-maint-list(a)redhat.com
Reporter: jsynacek(a)redhat.com
QA Contact: qe-baseos-apps(a)redhat.com
CC: cweyl(a)alumni.drew.edu, hyc(a)symas.com,
iarnell(a)gmail.com, jplesnik(a)redhat.com, kasal(a)ucw.cz,
lkundrak(a)v3.sk, mmaslano(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com, rc040203(a)freenet.de,
tcallawa(a)redhat.com
Depends On: 967719
Group: devel
External Bug ID: OpenLDAP ITS 7573
+++ This bug was initially created as a clone of Bug #967719 +++
Description of problem:
When trying to initialize back_perl, a segfault occurs deep in perl itself.
Version-Release number of selected component (if applicable):
perl-5.16.3-264.fc19.x86_64
openldap-2.4.35-4.fc19.x86_64
How reproducible:
Almost always.
Steps to Reproduce:
1. Install fresh F19
2. If you try the reproducer here, all goes well
3. yum install perl-A* (I have no idea why I needed to do this to get it to
segfault)
4. Try reproducer
5. Observe the segfault
6. From now on, reproducer works *without* producing any segfaults. I had to
reboot the machine to be able to reproduce the issue again.
Note on how to use the reproducer:
1. Unpack
2. Run go.sh (warning: it will wipe your /var/lib/ldap/* and your
/etc/openldap/*, so don't run if you use openldap in production)
This will run slapd in debug mode, so you will need another console to run
the rest.
3. Run try.sh
4. If you want to repeat, go to 2.
You can modify go.sh to run slapd through a debugger. However, you will
probably need to set LD_PRELOAD=/usr/lib64/perl5/CORE/libperl.so to be able to
run try.sh.
Actual results:
Perl segfaults.
Expected results:
The back_perl gets initialized without any problems.
Additional info:
This also happens on my production F18, but it happens always. It looks like it
might have something to do with Bug 960048.
--- Additional comment from Jan Synacek on 2013-05-28 08:53:11 CEST ---
Note that in the frame #3, the my_perl variable changes from a (probably valid)
pointer to 0x0.
--- Additional comment from Petr Pisar on 2013-07-03 14:38:09 CEST ---
What's expected output on the client site?
I have patched perl so that it links all XS modules to libperl.so explicitly in
my private F20 machine, and I do not get any segfaults. Instead I just get an
error message from the second command:
$ sh try.sh
SASL/EXTERNAL authentication started
SASL username: gidNumber=500+uidNumber=500,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"
ldap_add: Insufficient access (50)
SASL/EXTERNAL authentication started
SASL username: gidNumber=500+uidNumber=500,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase=perl,cn=config"
ldap_add: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax
I guess this is how to should work.
If this is the real fix, than this issue will be fixed in F20.
--- Additional comment from Jan Synacek on 2013-07-03 14:57:38 CEST ---
All LDAP operations should succeed without any errors. You don't have
sufficient access rights to modify the LDAP database. Running the script as
root should do it.
You should see something like this:
# ./try.sh
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase=perl,cn=config"
ldap_result: Can't contact LDAP server (-1)
The last line indicates the termination (you can see that slapd segfaulted in
the console where you ran go.sh). Expected output would look like the one above
minus the 'ldap_result: ...' line. Plus there may be one additional 'adding new
entry' line.
--- Additional comment from Petr Pisar on 2013-07-03 16:07:01 CEST ---
I run it as a non-root. I get much better results as a root:
# ./try.sh
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=module,cn=config"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase=perl,cn=config"
adding new entry "dc=perl-example,dc=com"
However the server sometimes segfaults as you reported.
--- Additional comment from Jan Synacek on 2013-07-04 07:54:23 CEST ---
(In reply to Petr Pisar from comment #4)
> I run it as a non-root. I get much better results as a root:
Yes, that's how the output is supposed to look.
> However the server sometimes segfaults as you reported.
Ok, it's strange that it segfaults only sometimes. Does this mean that you can
reproduce it even with all the perl modules linked to libperl.so explicitly?
--- Additional comment from Petr Pisar on 2013-07-04 09:07:56 CEST ---
I recompiled only modules in perl binary package and openldap for the test. Not
yet all modules that exist. I also reverted the RTLD_GLOBAL patch and checked
slapd does not crashes on linkage error. So the test does not use any
not-yet-rebuild modules.
I conclude this issue is independent on the linking bug #960048. But we will
see more after rebuilding everything.
--- Additional comment from Fedora Admin XMLRPC Client on 2013-08-12 13:50:07
CEST ---
This package has changed ownership in the Fedora Package Database. Reassigning
to the new owner of this component.
--- Additional comment from Howard Chu on 2013-10-13 02:20:16 CEST ---
Please also followup to OpenLDAP ITS#7573 with any conclusions you reach,
thanks.
--- Additional comment from Jan Synacek on 2013-10-16 08:13:38 CEST ---
This problem still occurs in F20.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=967719
[Bug 967719] Segfault in Perl_gv_fetchpvn_flags when trying to initialize
back_perl openldap backend
--
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=RTtoq7IB5n&a=cc_unsubscribe
7 years, 4 months
[Bug 808197] New: FTBFS: big endian bug in self checks
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: FTBFS: big endian bug in self checks
https://bugzilla.redhat.com/show_bug.cgi?id=808197
Summary: FTBFS: big endian bug in self checks
Product: Fedora
Version: 17
Platform: powerpc
OS/Version: Linux
Status: NEW
Severity: high
Priority: medium
Component: perl-Socket-Netlink
AssignedTo: bochecha(a)fedoraproject.org
ReportedBy: karsten(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com,
bochecha(a)fedoraproject.org
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Description of problem:
perl-Socket-Netlink fails to build on PPC as two of the self checks fail, one
of them looks like a big endian bug as the result has a swapped bit:
t/12netlink-message-header.t ..... ok
# Failed test '$message->attrs after unpack'
# at t/13netlink-message-attrs.t line 98.
# Structures begin differing at:
# $got->{str} = ''
# $expected->{str} = 'FGH'
# Looks like you failed 1 test of 14.
t/13netlink-message-attrs.t ......
Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/14 subtests
t/14netlink-message-error.t ...... ok
# Failed test '$message->pack'
# at t/20io-socket-netlink-generic.t line 55.
# at bytes 0-0xf (0-15)
# got: | 00 00 00 14 00 1e 00 00 00 00 00 00 00 00 00 00 |................|
# exp: | 00 00 00 14 00 00 00 1e 00 00 00 00 00 00 00 00 |................|
# Looks like you failed 1 test of 13.
Version-Release number of selected component (if applicable):
perl-Socket-Netlink-0.03-4.fc17
How reproducible:
always
Steps to Reproduce:
1. ppc-koji build --scratch f17 perl-Socket-Netlink-0.03-4.fc17.src.rpm
2.
3.
Actual results:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=469988
--
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.
7 years, 5 months
[Bug 671445] New: [PATCH] specfile accords to new packaging guidelines
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] specfile accords to new packaging guidelines
https://bugzilla.redhat.com/show_bug.cgi?id=671445
Summary: [PATCH] specfile accords to new packaging guidelines
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
Created attachment 474630
--> https://bugzilla.redhat.com/attachment.cgi?id=474630
add epel option
This patch should remove things, which are not needed according to new
packaging guidelines and latest rpm eg. defining buildroot. The old
behaviour is available under --epel option.
--
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.
7 years, 5 months
[Bug 807793] New: Please build pcsc-perl for EPEL6
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: Please build pcsc-perl for EPEL6
https://bugzilla.redhat.com/show_bug.cgi?id=807793
Summary: Please build pcsc-perl for EPEL6
Product: Fedora
Version: rawhide
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: unspecified
Priority: unspecified
Component: pcsc-perl
AssignedTo: tmraz(a)redhat.com
ReportedBy: mjeanson(a)rlnx.com
QAContact: extras-qa(a)fedoraproject.org
CC: tmraz(a)redhat.com, fedora-perl-devel-list(a)redhat.com
Classification: Fedora
Story Points: ---
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Hi,
I was hoping that you could build pcsc-perl for EPEL6.
I just tried a scratch build of the fc17 version and it builds without
modification within EPEL6.
http://koji.fedoraproject.org/koji/taskinfo?taskID=3940535
Thanks,
Michael
--
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.
7 years, 6 months
[Bug 1101265] New: perl-libwww-perl: incorrect handling of SSL certificate verification [fedora-all]
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1101265
Bug ID: 1101265
Summary: perl-libwww-perl: incorrect handling of SSL
certificate verification [fedora-all]
Product: Fedora
Version: 20
Component: perl-LWP-Protocol-https
Keywords: FutureFeature
Severity: high
Priority: high
Assignee: ppisar(a)redhat.com
Reporter: ppisar(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: jpazdziora(a)redhat.com, jplesnik(a)redhat.com,
mmaslano(a)redhat.com, mzazrivec(a)redhat.com,
perl-devel(a)lists.fedoraproject.org, ppisar(a)redhat.com,
psabata(a)redhat.com
+++ This bug was initially created as a clone of Bug #1094442 +++
[...]
--- Additional comment from Jan Pazdziora on 2014-05-26 10:55:43 GMT ---
(In reply to Petr Pisar from comment #9)
> Thank you for the report. However there are two mistakes:
>
> (1) The IO::Socket::SSL::new option is "SSL_verifycn_scheme", not
> "SSL_verifycn_schema". Thus you could not find it in the documentation.
Ahh, sorry about that
.
> (2) The 6.04-3 behavior was flawed. As you can read in the upstream bug
> report, the "SSL_verify_mode" option is about checking hostname. It's not
> intended to control certificate validation. The same applies to
> "PERL_LWP_SSL_VERIFY_HOSTNAME" environment variable. 6.04-4 has restored the
> behavior which presented before 6.04.
So what is the way for making HTTP requests to websites with self-signed
certificates from perl, if the user does not care about the CA chain
validation?
In other way, what is the way for making LWP behave the same way it used to
behave with pre-6 version?
--- Additional comment from Petr Pisar on 2014-05-26 11:20:51 GMT ---
There is no LWP environment variable or command line option to control that
currently.
It's possible to pass ssl_opts => {SSL_verify_mode =>
IO::Socket::SSL::SSL_VERIFY_NONE} to LWP::UserAgent::new if you write your own
LWP application.
This is also discussed in the upstream report.
The reason why the PERL_LWP_SSL_VERIFY_HOSTNAME seemed to work before is the
IO::Socket::SSL < 1.950 defaulted to SSL_VERIFY_NONE. This has not been true
since Fedora 20. Unfortunately Fedora 20 delivered the flawed
LWP::Protocol::https, so it was not visible.
I agree with you that there should be way how to disable the certificate
validation externally.
--
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=vNjL2yMVw5&a=cc_unsubscribe
7 years, 9 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, 9 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, 9 months