[Bug 1273668] New: to_string() appends 'undef' to array attribute
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1273668
Bug ID: 1273668
Summary: to_string() appends 'undef' to array attribute
Product: Fedora EPEL
Version: epel7
Component: perl-Exception-Base
Severity: low
Assignee: paul(a)city-fan.org
Reporter: jim(a)apnic.net
QA Contact: extras-qa(a)fedoraproject.org
CC: paul(a)city-fan.org, perl-devel(a)lists.fedoraproject.org
Description of problem:
Invoking to_string has the side effect of appending 'undef' to an array
attribute.
Version-Release number of selected component (if applicable):
perl-Exception-Base-0.2500-1.el7.noarch.rpm
perl v5.16.3
How reproducible:
Always
Steps to Reproduce:
Can reproduce with this perl script:
#!/bin/perl
use warnings;
use strict;
use Data::Dumper;
use Exception::Base
'MyException', => {
message => 'Validation error',
has => [ qw(class errors) ],
string_attributes => [ 'message', 'class', 'errors' ]
};
eval {
MyException->throw(
class => __PACKAGE__,
errors => ["error 1", "error 2", "error 3"]
);
};
my $exception = $@;
print( Dumper($exception->errors()) . "\n");
$exception->to_string();
print( Dumper($exception->errors()) . "\n");
Actual results:
Can see an additional 'undef' in the array returned after invoking to_string();
Expected results:
The returned array should be the same as when thrown.
Additional info:
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 9Â months
[Bug 1333910] New: dspam-web package doesn't create "dspam" user
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1333910
Bug ID: 1333910
Summary: dspam-web package doesn't create "dspam" user
Product: Fedora EPEL
Version: epel7
Component: dspam
Severity: medium
Assignee: nathanael(a)gnat.ca
Reporter: ggiesen+redhat(a)giesen.me
QA Contact: extras-qa(a)fedoraproject.org
CC: nathanael(a)gnat.ca, perl-devel(a)lists.fedoraproject.org
Description of problem:
The dspam-web package doesn't create "dspam" user. If you install it then
restart httpd without either adding the user or modifying the dspam-web.conf
file to use another user for SuexecUserGroup, then httpd will die on restart
because the user doesn't exist.
Version-Release number of selected component (if applicable):
3.10.2-11
How reproducible:
Always
Steps to Reproduce:
1. Install dspam-web
2. Restart httpd
Actual results:
httpd fails to restart
Expected results:
httpd restarts successfully without having to manually create the user or
modify the config file.
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 9Â months
[Bug 1357698] New:
perl-Catalyst-Runtime-5.80033-1.el6.noarch missing dependencies
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1357698
Bug ID: 1357698
Summary: perl-Catalyst-Runtime-5.80033-1.el6.noarch missing
dependencies
Product: Fedora EPEL
Version: el6
Component: perl-Catalyst-Runtime
Severity: high
Assignee: ppisar(a)redhat.com
Reporter: dcook(a)prosentient.com.au
QA Contact: extras-qa(a)fedoraproject.org
CC: iarnell(a)gmail.com, perl-devel(a)lists.fedoraproject.org,
ppisar(a)redhat.com, tremble(a)tremble.org.uk
Description of problem:
perl-Catalyst-Runtime-5.80033-1.el6.noarch is missing the following
dependencies when installed on RHEL 6.8 with EPEL 6,
rhel-6-server-optional-rpms, and rhel-6-server-extras-rpms repositories
enabled:
Requires: perl(MooseX::Types::Common::Numeric)
Requires: perl(MooseX::MethodAttributes::Inheritable) >= 0.24
Requires: perl(MooseX::Emulate::Class::Accessor::Fast) >= 0.00903
Requires: perl(MooseX::MethodAttributes)
Requires: perl(HTTP::Request::AsCGI) >= 1.0
How reproducible: always
Steps to Reproduce:
1. yum install perl-Catalyst-Runtime
Actual results:
Requires: perl(MooseX::Types::Common::Numeric)
Requires: perl(MooseX::MethodAttributes::Inheritable) >= 0.24
Requires: perl(MooseX::Emulate::Class::Accessor::Fast) >= 0.00903
Requires: perl(MooseX::MethodAttributes)
Requires: perl(HTTP::Request::AsCGI) >= 1.0
Expected results:
Successful installation.
Additional info:
I'm guessing that these 5 modules might have been orphaned and removed from
EPEL 6?
Locally, I just built RPMs of them using cpanspec, so I worked around this
issue, but I thought that I'd report it here. Some of these dependencies have
other dependencies which also need to be packaged.
I've reviewed https://fedoraproject.org/wiki/EPEL_Package_Maintainers and I
might consider trying to become a package maintainer, although I'm not sure how
much I could commit to maintaining these packages for a long period of time.
--
You are receiving this mail because:
You are on the CC list for the bug.
7Â years, 9Â months