rpms/perl-XML-XQL/EL-5 XML-XQL-filter-provides.sh, NONE, 1.1 perl-XML-XQL.spec, 1.4, 1.5
by Steven Pritchard
Author: steve
Update of /cvs/pkgs/rpms/perl-XML-XQL/EL-5
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv23114
Modified Files:
perl-XML-XQL.spec
Added Files:
XML-XQL-filter-provides.sh
Log Message:
Sync with devel.
--- NEW FILE XML-XQL-filter-provides.sh ---
#!/bin/sh
# Remove unversioned XML::XQL and bogus XML::DOM provides.
@@PERL_PROV@@ "$@" | sed -e '/^perl(XML::\(DOM::\|XQL)$\)/d'
Index: perl-XML-XQL.spec
===================================================================
RCS file: /cvs/pkgs/rpms/perl-XML-XQL/EL-5/perl-XML-XQL.spec,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- perl-XML-XQL.spec 1 Sep 2006 02:53:58 -0000 1.4
+++ perl-XML-XQL.spec 10 Dec 2007 17:09:33 -0000 1.5
@@ -1,61 +1,58 @@
Name: perl-XML-XQL
Version: 0.68
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: Perl module for querying XML tree structures with XQL
-
-Group: Development/Libraries
License: GPL or Artistic
+Group: Development/Libraries
URL: http://search.cpan.org/dist/XML-XQL/
Source0: http://www.cpan.org/authors/id/T/TJ/TJMATHER/XML-XQL-%{version}.tar.gz
Patch0: %{name}-tput-147465.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
-BuildRequires: perl(XML::DOM) >= 1.29
-BuildRequires: perl(Date::Manip)
+BuildRequires: perl(Date::Manip) >= 5.33
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(LWP::UserAgent)
BuildRequires: perl(Parse::Yapp)
+BuildRequires: perl(XML::DOM) >= 1.29
+BuildRequires: perl(XML::Parser) >= 2.30
Requires: perl(XML::DOM)
-Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
+
+Source99: XML-XQL-filter-provides.sh
+%global real_perl_provides %{__perl_provides}
+%define __perl_provides %{_tmppath}/%{name}-%{version}-%{release}-%(%{__id_u} -n)-filter-provides
%description
This is a Perl extension that allows you to perform XQL queries on XML
object trees. Currently only the XML::DOM module is supported, but
other implementations, like XML::Grove, may soon follow.
-
%prep
%setup -q -n XML-XQL-%{version}
%patch0 -p0
-cat <<EOF > %{name}-prov
-#!/bin/sh
-# Filter versionless XML::XQL, we expect perl.prov to emit the versioned one.
-%{__perl_provides} \$* | grep -v 'perl(XML::\(DOM::\|XQL)$\)'
-EOF
-%define __perl_provides %{_builddir}/XML-XQL-%{version}/%{name}-prov
+sed -e 's,@@PERL_PROV@@,%{real_perl_provides},' %{SOURCE99} > %{__perl_provides}
chmod +x %{__perl_provides}
-
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
-rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -type d -depth -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w %{buildroot}/*
+rm -rf $RPM_BUILD_ROOT
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
%check
make test
-
%clean
-rm -rf %{buildroot}
-
+rm -rf $RPM_BUILD_ROOT %{__perl_provides}
%files
%defattr(-,root,root,-)
@@ -64,8 +61,13 @@
%{perl_vendorlib}/XML/
%{_mandir}/man3/XML::XQL*.3*
-
%changelog
+* Wed Apr 18 2007 Steven Pritchard <steve(a)kspei.com> 0.68-4
+- Reformat to match cpanspec output.
+- Fix find option order.
+- Use fixperms macro instead of our own chmod incantation.
+- BR ExtUtils::MakeMaker.
+
* Mon Aug 27 2006 Michael J. Knox <michael[AT]knox.net.nz> - 0.68-3
- Rebuild for FC6
16 years, 4 months
[Bug 250862] New: Please rebuild perl-BerkeleyDB for EPEL 4 and 5
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=250862
Summary: Please rebuild perl-BerkeleyDB for EPEL 4 and 5
Product: Fedora
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-BerkeleyDB
AssignedTo: steve(a)silug.org
ReportedBy: redhat-bugzilla(a)linuxnetz.de
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Please rebuild perl-BerkeleyDB for EPEL 4 and 5
Version-Release number of selected component (if applicable):
perl-BerkeleyDB-0.32-1
Actual results:
No perl-BerkeleyDB in EPEL 4 and 5
Expected results:
Package perl-BerkeleyDB in EPEL 4 and 5, because it's an amavisd-new
dependency.
Additional info:
Please let me know, when you're not interested in maintaining the package
there.
Rebuild in mock looks NOT well:
0:perl-Test-Pod-1.26-1.el5.noarch
4:perl-5.8.8-10.i386
No Package Found for perl(MLDBM)
0:db4-devel-4.3.29-9.fc6.i386
Cannot find build req perl(MLDBM). Exiting.
--
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.
16 years, 4 months
[Bug 250872] New: perl-FreezeThaw-0.43-5
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=250872
Summary: perl-FreezeThaw-0.43-5
Product: Fedora
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-FreezeThaw
AssignedTo: jpo(a)di.uminho.pt
ReportedBy: redhat-bugzilla(a)linuxnetz.de
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Please rebuild perl-FreezeThaw for EPEL 4 and 5
Version-Release number of selected component (if applicable):
perl-FreezeThaw-0.43-5
Actual results:
No perl-FreezeThaw in EPEL 4 and 5
Expected results:
Package perl-FreezeThaw in EPEL 4 and 5, because it's a perl-MLDBM dependency.
Additional info:
Please let me know, when you're not interested in maintaining the package
there.
Mockbuild in EPEL 5 succeded for me and looks fine, too:
Wrote: /builddir/build/RPMS/perl-FreezeThaw-0.43-5.el5.noarch.rpm
--
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.
16 years, 4 months
[Bug 250873] New: Please rebuild perl-MLDBM for EPEL 4 and 5
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=250873
Summary: Please rebuild perl-MLDBM for EPEL 4 and 5
Product: Fedora
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-MLDBM
AssignedTo: jpo(a)di.uminho.pt
ReportedBy: redhat-bugzilla(a)linuxnetz.de
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
Description of problem:
Please rebuild perl-MLDBM for EPEL 4 and 5
Version-Release number of selected component (if applicable):
perl-MLDBM-2.01-5
Actual results:
No perl-MLDBM in EPEL 4 and 5
Expected results:
Package perl-MLDBM in EPEL 4 and 5, because it's a perl-BerkeleyDB dependency.
Additional info:
Please let me know, when you're not interested in maintaining the package
there.
--
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.
16 years, 4 months
rpms/perl-Crypt-OpenSSL-AES/devel perl-Crypt-OpenSSL-AES.spec, 1.3, 1.4
by Jesse Keating
Author: jkeating
Update of /cvs/pkgs/rpms/perl-Crypt-OpenSSL-AES/devel
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv19411
Modified Files:
perl-Crypt-OpenSSL-AES.spec
Log Message:
* Sun Dec 09 2007 Release Engineering <rel-eng at fedoraproject dot org> - 0.03-2
- Rebuild for deps
Index: perl-Crypt-OpenSSL-AES.spec
===================================================================
RCS file: /cvs/pkgs/rpms/perl-Crypt-OpenSSL-AES/devel/perl-Crypt-OpenSSL-AES.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- perl-Crypt-OpenSSL-AES.spec 6 Dec 2007 16:22:49 -0000 1.3
+++ perl-Crypt-OpenSSL-AES.spec 9 Dec 2007 21:25:13 -0000 1.4
@@ -1,6 +1,6 @@
Name: perl-Crypt-OpenSSL-AES
Version: 0.03
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Perl interface to OpenSSL for AES
License: GPL or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@
%{_mandir}/man3/*
%changelog
+* Sun Dec 09 2007 Release Engineering <rel-eng at fedoraproject dot org> - 0.03-2
+- Rebuild for deps
+
* Thu Dec 6 2007 Wes Hardaker <wjhns174(a)hardakers.net> - 0.03-1
- Bump to force rebuild with new openssl lib version
16 years, 4 months
groups as owners in pkgdb (was: Re: time for perl 5.10.x in devel?)
by Chris Weyl
It bounced -- I forwarded back on 11/28.
On Nov 28, 2007 9:21 AM, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
> Chris, if this bounces from the list, feel free to forward it there.
>
> Chris Weyl wrote:
> > On Nov 28, 2007 6:25 AM, Tom spot Callaway <tcallawa(a)redhat.com> wrote:
> >> On Wed, 2007-11-28 at 14:46 +0100, Ralf Corsepius wrote:
> >>> On Wed, 2007-11-28 at 14:35 +0100, Patrice Dumas wrote:
> >>>> Maybe the solution could simply be to be able to add some comments in the
> >>>> pacakgedb, telling who is really allowed to touch the package?
> >>>> and select 'group members can commit?'.
> >>> IMO, the easiest approach would be to use "perl-sig" or similar (eg. an
> >>> "email alias" or a packagedb "alias" (should such thing exist)) as
> >>> owner ;)
> >> Which, we can't do, without dirty hacks, currently.
> >>
> >> You should talk to Toshio about this.
> >
> > I'm unfamiliar with the limitations of the accounts/grouping/packagedb
> > system, but if we can have the accounts system enforce a requirement
> > that members of one group must be a subset of another group (e.g.
> > perl-sig group members must be members of the cla-done group), would
> > this satisfy the requirement that all package owners have signed
> > CLA's?
>
> Yes, this part is currently possible. We're changing over to an LDAP
> backend and better web frontend in a few months, though, so I don't know
> the limitations and abilities of that system.
>
> One other thing is that people would need to be a member of cvsextras as
> well as cla_done in order to login to the cvs server.
Excellent. So it sounds like we can rig things such that there should
be no legal issues to group ownership that I see -- though IANAL =)
> > Can we have a group own a package?
> >
> Not currently. Pseudo groups like the current perl-sig can own a
> package but a real group cannot. This requires a bit of recoding in
> order to change.
>
> OTOH, letting a group be comaintainer (equivalent rights to owner) of a
> package is fairly complete (there are a few places where we are
> currently checking for cvsextras explicitly, but we can change those to
> list other groups without much difficulty.
>
> The biggest area where group ownership won't work precisely right at
> this time is in the webUI. cvsextras is our only current group and we
> aren't showing all the acls for it, just the commit acl. For the
> perl-sig, I imagine that you'll want to have at least commit,
> watchbugzilla, and watchcommits set. I can code this into the
> commandline tool admins are using to set permissions but doing the same
> for the webUI will require some rethinking of what it should look like
> and how complex it should be.
Exactly it, AFAIK. All members of perl-sig should be subscribed to
this group, so I suspect individual emails to the group members may be
a touch redundant.
If we were to do this prior to any impending work, I'd say make it as
quick and easy as possible (no sense doing something just to rework
it). I don't know if anyone else is clamoring for this capability
yet.
> > I'm buying what Ralf is saying here: to attempt to have collective
> > ownership via individual ownership and extensive co-maintainers is
> > another variant of "dirty hacks".
> >
> Agreed. If you want to move forward with getting this working in the
> packagedb you should open a ticket[1]_, we can try and record all the
> changes we need in the packagedb and account system to enable the
> change. Then I can talk to the FAS2 author to be sure it won't cause
> him any grief when we migrate and we can code something up.
>
> We're shooting to deploy FAS2 in February. So if there are
> interdependencies between FAS and pkgdb that should wait on that
> deployment we would do so after that.
Done!
https://hosted.fedoraproject.org/projects/packagedb/ticket/109
I tried to be succinct; if there's additional verbiage needed I'd be
more than happy to update the ticket.
-Chris
--
Chris Weyl
Ex astris, scientia
16 years, 4 months
rpms/perl-GSSAPI/devel perl-GSSAPI.spec,1.5,1.6
by Steven Pritchard
Author: steve
Update of /cvs/pkgs/rpms/perl-GSSAPI/devel
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv8759
Modified Files:
perl-GSSAPI.spec
Log Message:
Update License tag.
Use fixperms macro instead of our own chmod incantation.
Source in /etc/profile.d/krb5-devel.sh to get our path right.
Index: perl-GSSAPI.spec
===================================================================
RCS file: /cvs/pkgs/rpms/perl-GSSAPI/devel/perl-GSSAPI.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- perl-GSSAPI.spec 22 Feb 2007 10:53:04 -0000 1.5
+++ perl-GSSAPI.spec 9 Dec 2007 00:59:36 -0000 1.6
@@ -6,11 +6,11 @@
Name: perl-GSSAPI
Version: 0.24
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: Perl extension providing access to the GSSAPIv2 library
Group: Development/Libraries
-License: GPL or Artistic
+License: GPL+ or Artistic
URL: http://search.cpan.org/dist/GSSAPI/
Source0: http://www.cpan.org/authors/id/A/AG/AGROLMS/GSSAPI-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
@@ -32,6 +32,7 @@
%build
+. /etc/profile.d/krb5-devel.sh
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
make %{?_smp_mflags}
@@ -42,7 +43,7 @@
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -63,6 +64,11 @@
%changelog
+* Sat Dec 08 2007 Steven Pritchard <steve(a)kspei.com> 0.24-2
+- Update License tag.
+- Use fixperms macro instead of our own chmod incantation.
+- Source in /etc/profile.d/krb5-devel.sh to get our path right.
+
* Thu Feb 22 2007 Jose Pedro Oliveira <jpo at di.uminho.pt> - 0.24-1
- Update to 0.24.
16 years, 4 months
rpms/perl-BerkeleyDB/EL-4 .cvsignore, 1.2, 1.3 perl-BerkeleyDB.spec, 1.2, 1.3 sources, 1.2, 1.3
by Steven Pritchard
Author: steve
Update of /cvs/pkgs/rpms/perl-BerkeleyDB/EL-4
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv18479
Modified Files:
.cvsignore perl-BerkeleyDB.spec sources
Log Message:
Rebuild on EL-4 without Test::Pod.
Index: .cvsignore
===================================================================
RCS file: /cvs/pkgs/rpms/perl-BerkeleyDB/EL-4/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- .cvsignore 2 Aug 2005 23:43:35 -0000 1.2
+++ .cvsignore 8 Dec 2007 22:08:43 -0000 1.3
@@ -1 +1 @@
-BerkeleyDB-0.26.tar.gz
+BerkeleyDB-0.32.tar.gz
Index: perl-BerkeleyDB.spec
===================================================================
RCS file: /cvs/pkgs/rpms/perl-BerkeleyDB/EL-4/perl-BerkeleyDB.spec,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- perl-BerkeleyDB.spec 3 Aug 2005 19:06:03 -0000 1.2
+++ perl-BerkeleyDB.spec 8 Dec 2007 22:08:43 -0000 1.3
@@ -1,17 +1,17 @@
-%{!?perl_vendorarch: %define perl_vendorarch %(eval "`%{__perl} -V:installvendorarch`"; echo $installvendorarch)}
-
Name: perl-BerkeleyDB
-Version: 0.26
-Release: 3%{?dist}
-Summary: BerkeleyDB Perl module
+Version: 0.32
+Release: 0.1%{?dist}
+Summary: Perl extension for Berkeley DB version 2, 3 or 4
License: GPL or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/BerkeleyDB/
-Source0: http://www.cpan.org/modules/by-module/BerkeleyDB/BerkeleyDB-0.26.tar.gz
+Source0: http://www.cpan.org/authors/id/P/PM/PMQS/BerkeleyDB-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: db4-devel
+BuildRequires: perl(ExtUtils::MakeMaker)
# For "make test".
-BuildRequires: perl(Test::Pod), perl(MLDBM)
+BuildRequires: perl(MLDBM)
+#BuildRequires: perl(Test::Pod)
Requires: perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo $version))
%description
@@ -28,7 +28,6 @@
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE="$RPM_OPT_FLAGS"
-%{__perl} -pi -e 's/^\tLD_RUN_PATH=[^\s]+\s*/\t/' Makefile
make %{?_smp_mflags}
%install
@@ -40,11 +39,11 @@
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2>/dev/null \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2>/dev/null \;
-chmod -R u+rwX,go+rX,go-w $RPM_BUILD_ROOT/*
+%{_fixperms} $RPM_BUILD_ROOT/*
-%check || :
+%check
make test
%clean
@@ -53,12 +52,56 @@
%files
%defattr(-,root,root,-)
%doc Changes README Todo
-%{perl_vendorarch}/BerkeleyDB*
%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/BerkeleyDB*
%{_mandir}/man3/*
%{_bindir}/*
%changelog
+* Tue Dec 04 2007 Steven Pritchard <steve(a)kspei.com> 0.32-0.1
+- Rebuild on EL-4 without Test::Pod.
+
+* Fri Jul 13 2007 Steven Pritchard <steve(a)kspei.com> 0.32-1
+- Update to 0.32.
+
+* Tue Apr 17 2007 Steven Pritchard <steve(a)kspei.com> 0.31-3
+- BR ExtUtils::MakeMaker.
+
+* Mon Oct 16 2006 Steven Pritchard <steve(a)kspei.com> 0.31-2
+- Rebuild.
+
+* Mon Oct 16 2006 Steven Pritchard <steve(a)kspei.com> 0.31-1
+- Update to 0.31.
+- Use fixperms macro instead of our own chmod incantation.
+
+* Wed Sep 13 2006 Steven Pritchard <steve(a)kspei.com> 0.30-1
+- Update to 0.30.
+
+* Mon Aug 28 2006 Steven Pritchard <steve(a)kspei.com> 0.29-2
+- Minor spec cleanup.
+
+* Fri Jul 07 2006 Steven Pritchard <steve(a)kspei.com> 0.29-1
+- Update to 0.29.
+
+* Fri Jun 30 2006 Steven Pritchard <steve(a)kspei.com> 0.28-1
+- Update to 0.28
+
+* Sat Feb 18 2006 Steven Pritchard <steve(a)kspei.com> 0.27-2
+- Rebuild
+
+* Tue Jan 10 2006 Steven Pritchard <steve(a)kspei.com> 0.27-1
+- Update to 0.27
+
+* Wed Oct 12 2005 Steven Pritchard <steve(a)kspei.com> 0.26-6
+- Another rebuild
+
+* Sat Sep 24 2005 Steven Pritchard <steve(a)kspei.com> 0.26-5
+- Rebuild for new db4 in rawhide
+
+* Mon Sep 05 2005 Steven Pritchard <steve(a)kspei.com> 0.26-4
+- Spec cleanup
+- Include COPYING and Artistic
+
* Wed Aug 03 2005 Steven Pritchard <steve(a)kspei.com> 0.26-3
- Move OPTIMIZE to Makefile.PL instead of make
Index: sources
===================================================================
RCS file: /cvs/pkgs/rpms/perl-BerkeleyDB/EL-4/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- sources 2 Aug 2005 23:43:35 -0000 1.2
+++ sources 8 Dec 2007 22:08:43 -0000 1.3
@@ -1 +1 @@
-6e9882f4e4bac48b24079d082af30e6c BerkeleyDB-0.26.tar.gz
+df74b8d381d08b17ada69185b45e06a6 BerkeleyDB-0.32.tar.gz
16 years, 4 months
[Bug 398271] New: Branching request for EPEL
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=398271
Summary: Branching request for EPEL
Product: Fedora
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-Unicode-MapUTF8
AssignedTo: gauret(a)free.fr
ReportedBy: athienem(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
perl-Unicode-MapUTF8 is not available in EPEL.
Please branch the package accordingly for EL-5 and optionally for EL-4.
Thanks.
If you're short on time, not interested or simply need help maintaining it in
EPEL I'd be glad to (co-)maintain the EPEL Branch with/for you.
--
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.
16 years, 4 months
[Bug 398251] New: Branching request for EPEL
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=398251
Summary: Branching request for EPEL
Product: Fedora
Version: devel
Platform: All
OS/Version: Linux
Status: NEW
Severity: low
Priority: low
Component: perl-Unicode-Map8
AssignedTo: gauret(a)free.fr
ReportedBy: athienem(a)redhat.com
QAContact: extras-qa(a)fedoraproject.org
CC: fedora-perl-devel-list(a)redhat.com
perl-Unicode-Map8 is not available in EPEL.
Please branch the package accordingly for EL-5 and optionally for EL-4.
Thanks.
If you're short on time, not interested or simply need help maintaining it in
EPEL I'd be glad to (co-)maintain the EPEL Branch with/for you.
--
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.
16 years, 4 months