Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 20.1.2012 00:31, Stephen Gallagher wrote: Currently, the official bug lifecycle includes the following phrase: The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report. I've seen quite a few bugs lately closed with this resolution (mostly in the Evolution and GNOME projects for me personally). It seems to me that this is terribly useless in terms of informing users when their bugs are fixed. You are completely right, except: * since I wrote http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ nobody did anything on numerous Bugzilla bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=123130, https://bugzilla.mozilla.org/show_bug.cgi?id=380493 ... if you know about any Perl hacker who would be willing to help, these bugs could be a good place to start, * BugZappers more or less failed to do any meaningful change in the state of our Bugzilla (that's to the large part my failure, but that's how it is) and there is just too few of them, * this really sounds like proverbial somebody else should do something ... Best, Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 01/20/2012 08:39 AM, Marcela Mašláňová wrote: On 01/20/2012 12:31 AM, Stephen Gallagher wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. Users do! To them, what you are doing is to ignore them for now and to sit-out bugs, instead. Whether they will find this tolerable or consider you to be a non-collaborations jerk widely depend on the actual impact the bug they reported has on them. I guess instead of closed/upstream we would see more closed/wontfix|cantfix. Delegating bugs for fixing to upstream, because you can't fix for whatever reasons isn't much of a problem. The problem is the attitude CLOSED UPSTEAM communicates: Cheating about the current shape a package is in Fedora. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes coming for CUPS 1.6
On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote: What a great idea! We could call one of them 'Postscript'... Not likely. :-) I think the current candidate for the optional vector format is PDF 1.4/1.5. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. I guess instead of closed/upstream we would see more closed/wontfix|cantfix. I use POST for that. A patch or solution believed to resolve this matter has been proposed (POSTed) for inclusion in the package or kernel. For non-kernel packages I read that as meaning that the patch is in-hand upstream, and not yet built in Fedora. Tim. */ signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20120120 changes
Compose started at Fri Jan 20 08:15:13 UTC 2012 Broken deps for x86_64 -- [amsn] amsn-0.98.4-4.fc16.x86_64 requires libgupnp-igd-1.0.so.3()(64bit) [anerley] 1:anerley-0.3.0-7.fc17.i686 requires libcogl.so.6 1:anerley-0.3.0-7.fc17.x86_64 requires libcogl.so.6()(64bit) [aunit] aunit-2010-3.fc16.i686 requires libgnat-4.6.so aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit) [blender] 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADAStreamWriter.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADAFramework.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libOpenCOLLADABaseUtils.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit) 1:blender-2.61-1.fc17.x86_64 requires libGeneratedSaxParser.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADAStreamWriter.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADASaxFrameworkLoader.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADAFramework.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libOpenCOLLADABaseUtils.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libMathMLSolver.so.svn863()(64bit) 1:blenderplayer-2.61-1.fc17.x86_64 requires libGeneratedSaxParser.so.svn863()(64bit) [clutter-gtk010] clutter-gtk010-0.11.4-3.fc17.i686 requires libcogl.so.6 clutter-gtk010-0.11.4-3.fc17.x86_64 requires libcogl.so.6()(64bit) [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [compat-gcc-34] compat-gcc-34-c++-3.4.6-23.fc17.x86_64 requires libstdc++ 0:4.7.0 [compiz] compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.i686 requires libboost_serialization-mt.so.1.47.0 compiz-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-gtk-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) compiz-kde-0.9.5.92.1-0.1.gite676f1b12eb8db3a76978eed5bfc7c2cf9a0b6ce.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [compiz-fusion-extras] compiz-fusion-extras-0.9.5.92-1.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [compiz-fusion-unsupported] compiz-fusion-unsupported-0.9.4-6.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [compiz-plugins-main] compiz-plugins-main-0.9.5.92-1.fc17.x86_64 requires libboost_serialization-mt.so.1.47.0()(64bit) [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [couchdb] couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) [curry] curry-0.9.11-7.fc12.x86_64 requires libgmp.so.3()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [ease] ease-0.4-14.fc17.i686 requires libcogl.so.6 ease-0.4-14.fc17.x86_64 requires libcogl.so.6()(64bit) [ember] ember-0.6.2-2.fc17.x86_64 requires ember-media = 0:0.6.2 [emerillon] emerillon-0.1.90-5.fc17.x86_64 requires libcogl.so.6()(64bit) [eog-plugins] eog-plugins-3.2.2-3.fc17.x86_64 requires libcogl.so.6()(64bit) [frysk] frysk-0.4-32.fc17.x86_64 requires libgcj.so.12()(64bit) frysk-devel-0.4-32.fc17.i386 requires libvtejava-0.12.so frysk-devel-0.4-32.fc17.i386 requires libgtkjava-2.10.so frysk-devel-0.4-32.fc17.i386 requires libglibjava-0.4.so frysk-devel-0.4-32.fc17.i386 requires libgladejava-2.12.so frysk-devel-0.4-32.fc17.i386 requires libgcj.so.12 frysk-devel-0.4-32.fc17.i386 requires libcairojava-1.0.so frysk-devel-0.4-32.fc17.x86_64 requires libvtejava-0.12.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libgtkjava-2.10.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libglibjava-0.4.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libgladejava-2.12.so()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libgcj.so.12()(64bit) frysk-devel-0.4-32.fc17.x86_64 requires libcairojava-1.0.so()(64bit) frysk-gnome-0.4-32.fc17.x86_64 requires libvtejava-0.12.so()(64bit) frysk-gnome-0.4-32.fc17.x86_64 requires libvte-java = 0:0.12.0 frysk-gnome-0.4-32.fc17.x86_64 requires
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 09:17 +0100, Matej Cepl wrote: On 20.1.2012 00:31, Stephen Gallagher wrote: Currently, the official bug lifecycle includes the following phrase: The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report. I've seen quite a few bugs lately closed with this resolution (mostly in the Evolution and GNOME projects for me personally). It seems to me that this is terribly useless in terms of informing users when their bugs are fixed. You are completely right, except: * since I wrote http://article.gmane.org/gmane.linux.redhat.fedora.devel/79936/ nobody did anything on numerous Bugzilla bugs like https://bugzilla.mozilla.org/show_bug.cgi?id=123130, https://bugzilla.mozilla.org/show_bug.cgi?id=380493 ... if you know about any Perl hacker who would be willing to help, these bugs could be a good place to start, That's a fantastic idea, and probably an ideal solution. Unfortunately, we're also talking about a minimum of several months' work to get that in place, just on the engineering side. Not including the deployment testing period. * BugZappers more or less failed to do any meaningful change in the state of our Bugzilla (that's to the large part my failure, but that's how it is) and there is just too few of them, I'm not sure about what you meant here. * this really sounds like proverbial somebody else should do something ... Well, the proposal I'm making is the one that I've been following personally in my own projects, which I feel is providing better service to my users. I agree that if we had the solution you propose above available, that would meet (or exceed) the same need. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. I guess instead of closed/upstream we would see more closed/wontfix|cantfix. I use POST for that. A patch or solution believed to resolve this matter has been proposed (POSTed) for inclusion in the package or kernel. For non-kernel packages I read that as meaning that the patch is in-hand upstream, and not yet built in Fedora. That's certainly one reasonable approach to this specific case, provided that we A) Document this interpretation more clearly. B) Comment in the bug that the patch is committed upstream and will be available when the equivalent upstream release arrives. I still think that the more ideal solution though is to keep the bug open until a package actually hits Fedora with that fix in it (be it an updated version or a cherry-picked patch). This way it's clear to the user exactly when they can expect a fix. Bonus: it tells users when a Bodhi update is available that will address their issue. This encourages more users to test. I've certainly noticed a marked increase in bodhi karma activity on my updates that have more bugs marked as addressed vs. those updates that just pull in a new upstream version without any Fedora-specific bugs reported. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
- Original Message - On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. I guess instead of closed/upstream we would see more closed/wontfix|cantfix. I use POST for that. A patch or solution believed to resolve this matter has been proposed (POSTed) for inclusion in the package or kernel. For non-kernel packages I read that as meaning that the patch is in-hand upstream, and not yet built in Fedora. That's certainly one reasonable approach to this specific case, provided that we A) Document this interpretation more clearly. B) Comment in the bug that the patch is committed upstream and will be available when the equivalent upstream release arrives. We already had this discussion, I don't recall exactly - two years ago and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM. I can try to find it :) As it's usually used this way - bug is reported to upstream (by reporter, us in case he does not have account or is not willing to do it), then the bug can bounce between Fedora/upstream (you know, everyone has to blame other side or sometimes it's not easy to say who to blame ;-). And the bug is actually not fixed in Fedora until we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state. The biggest problem here is just - some people misuse this CLOSED UPSTREAM as we don't care in Fedora. And they would use another CLOSED resolution to close the bug :) R. I still think that the more ideal solution though is to keep the bug open until a package actually hits Fedora with that fix in it (be it an updated version or a cherry-picked patch). This way it's clear to the user exactly when they can expect a fix. Bonus: it tells users when a Bodhi update is available that will address their issue. This encourages more users to test. I've certainly noticed a marked increase in bodhi karma activity on my updates that have more bugs marked as addressed vs. those updates that just pull in a new upstream version without any Fedora-specific bugs reported. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 08:04 -0500, Jaroslav Reznik wrote: - Original Message - On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. I guess instead of closed/upstream we would see more closed/wontfix|cantfix. I use POST for that. A patch or solution believed to resolve this matter has been proposed (POSTed) for inclusion in the package or kernel. For non-kernel packages I read that as meaning that the patch is in-hand upstream, and not yet built in Fedora. That's certainly one reasonable approach to this specific case, provided that we A) Document this interpretation more clearly. B) Comment in the bug that the patch is committed upstream and will be available when the equivalent upstream release arrives. We already had this discussion, I don't recall exactly - two years ago and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM. I can try to find it :) As it's usually used this way - bug is reported to upstream (by reporter, us in case he does not have account or is not willing to do it), then the bug can bounce between Fedora/upstream (you know, everyone has to blame other side or sometimes it's not easy to say who to blame ;-). And the bug is actually not fixed in Fedora until we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state. The biggest problem here is just - some people misuse this CLOSED UPSTREAM as we don't care in Fedora. And they would use another CLOSED resolution to close the bug :) A bigger problem would be that this claimed approach is not documented anywhere that anyone could find (short of digging through old mailing list archives). It seems to me that what we're looking at here is more of NEEDSINFO: upstream than any kind of CLOSED status. I think the bug should stay open as ASSIGNED and that the maintainer should be responsible for occasionally reporting back progress made on the upstream bug. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 01/20/2012 02:04 PM, Jaroslav Reznik wrote: - Original Message - On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: We already had this discussion, I don't recall exactly - two years ago and the resolution was similar - rename CLOSED UPSTREAM to HOLD UPSTREAM. I can try to find it :) As it's usually used this way - bug is reported to upstream (by reporter, us in case he does not have account or is not willing to do it), then the bug can bounce between Fedora/upstream (you know, everyone has to blame other side or sometimes it's not easy to say who to blame ;-). And the bug is actually not fixed in Fedora until we receive fix - then it can go to some CLOSED RAWHIDE/NEXTRELEASE state. The biggest problem here is just - some people misuse this CLOSED UPSTREAM as we don't care in Fedora. And they would use another CLOSED resolution to close the bug :) ... and why no simply keep these BZs open and/or to add a note Reported upstream and keep abrt open to receive more of them (This would at least provide an indicator for the severity of a bug)? This would at least reflect the actual situation in Fedora: Bug is still present. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
kexec-tools: sync with the latest upstream release
Hi, Neil and others, I plan to sync kexec-tools and makedumpfile with upstream release, IOW, move kexec-tools to 2.0.3 and makedumpfile to 1.4.1, for Fedora 17. Do you have any objections? Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 20 Jan 2012 07:20:20 -0500 Stephen Gallagher sgall...@redhat.com wrote: Well, the proposal I'm making is the one that I've been following personally in my own projects, which I feel is providing better service to my users. Speaking as a (mostly) user: I agree with this statement. I would rather have the bugs kept in the open state until a package with the fix is released, so that I can see when they are fixed in Fedora. Since I am not a package maintainer, I cannot estimate the impact of such a policy on the workload of those busy people. I can live with the current status quo. Just my EUR 0.02, --Stijn -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bad coding practices in Fedora packages
On 01/04/2012 10:36 AM, Michal Hlavinka wrote: On 01/03/2012 05:21 PM, Sérgio Basto wrote: I agree, at least for non-gnome users , tracker shouldn't be in autostart. https://bugzilla.redhat.com/show_bug.cgi?id=771601 Thank you Michal for opening a bug. I should learn from you: less complaining, more work towards achieving actual improvement... -- vda -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
An Easy But Serious Screensaver Security Problem In X.Org
Hopefully this is being addressed: http://www.phoronix.com/scan.php?page=news_itempx=MTA0NTA -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-URI] Spec clean-up
commit 5d64e5c56aace0d3158fd4777601c3316f168169
Author: Paul Howarth p...@city-fan.org
Date: Fri Jan 20 14:22:57 2012 +
Spec clean-up
- Break build dependency loop by only using perl(Business::ISBN) if we're
not
bootstrapping
- BR: perl(Carp) and perl(Exporter)
- Make %files list more explicit
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Use %{_fixperms} macro rather than our own chmod incantation
- Don't use macros for commands
.gitignore|6 +-
perl-URI.spec | 53 +++--
2 files changed, 36 insertions(+), 23 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4d3f096..796820b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1 @@
-URI-1.54.tar.gz
-/URI-1.55.tar.gz
-/URI-1.56.tar.gz
-/URI-1.58.tar.gz
-/URI-1.59.tar.gz
+/URI-[0-9.]*.tar.gz
diff --git a/perl-URI.spec b/perl-URI.spec
index 6d9c5e2..e57ad86 100644
--- a/perl-URI.spec
+++ b/perl-URI.spec
@@ -1,54 +1,71 @@
Name: perl-URI
Version:1.59
-Release:2%{?dist}
+Release:3%{?dist}
Summary:A Perl module implementing URI parsing and manipulation
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/URI/
Source0:http://www.cpan.org/authors/id/G/GA/GAAS/URI-%{version}.tar.gz
-
BuildArch: noarch
-BuildRequires: perl(MIME::Base64)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(MIME::Base64)
BuildRequires: perl(Test::More)
+# Business::ISBN - Test::Pod - Pod::Simple - HTML::Entities (HTML::Parser)
- URI
+%if 0%{!?perl_bootstrap:1}
BuildRequires: perl(Business::ISBN)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-
+%endif
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
This module implements the URI class. Objects of this class represent
Uniform Resource Identifier references as specified in RFC 2396 (and
updated by RFC 2732).
-
%prep
%setup -q -n URI-%{version}
chmod 644 uri-test
%build
-%{__perl} Makefile.PL INSTALLDIRS=perl
+perl Makefile.PL INSTALLDIRS=perl
make %{?_smp_mflags}
-
%install
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
-find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -type d -depth -exec rmdir {} ';' 2/dev/null
+%{_fixperms} %{buildroot}
%check
make test
-
%files
%doc Changes README uri-test
-%{perl_privlib}/URI*
-%{_mandir}/man3/*.3*
-
+%{perl_privlib}/URI.pm
+%{perl_privlib}/URI/
+%{_mandir}/man3/URI.3pm*
+%{_mandir}/man3/URI::Escape.3pm*
+%{_mandir}/man3/URI::Heuristic.3pm*
+%{_mandir}/man3/URI::QueryParam.3pm*
+%{_mandir}/man3/URI::Split.3pm*
+%{_mandir}/man3/URI::URL.3pm*
+%{_mandir}/man3/URI::WithBase.3pm*
+%{_mandir}/man3/URI::_punycode.3pm*
+%{_mandir}/man3/URI::data.3pm*
+%{_mandir}/man3/URI::file.3pm*
+%{_mandir}/man3/URI::ldap.3pm*
%changelog
+* Fri Jan 20 2012 Paul Howarth p...@city-fan.org - 1.59-3
+- Break build dependency loop by only using perl(Business::ISBN) if we're not
+ bootstrapping
+- BR: perl(Carp) and perl(Exporter)
+- Make %%files list more explicit
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Use %%{_fixperms} macro rather than our own chmod incantation
+- Don't use macros for commands
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.59-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: An Easy But Serious Screensaver Security Problem In X.Org
On Fri, 2012-01-20 at 10:11 -0500, Neal Becker wrote: Hopefully this is being addressed: http://www.phoronix.com/scan.php?page=news_itempx=MTA0NTA https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-0064 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 20.1.2012 13:20, Stephen Gallagher wrote: That's a fantastic idea, and probably an ideal solution. Unfortunately, we're also talking about a minimum of several months' work to get that in place, just on the engineering side. Not including the deployment testing period. Sure. Just to note that the email (and bugs) is old couple of years. * BugZappers more or less failed to do any meaningful change in the state of our Bugzilla (that's to the large part my failure, but that's how it is) and there is just too few of them, I'm not sure about what you meant here. That what you want from package maintainers is basically to do manually what I have described above. Which is fine for a component with five bugs, but for components like kernel, Firefox, or some of major Gnome components with hundreds of open bugs (on the top of other problems components infested with ABRT bugs), it means hundreds of hours of work (I know what I am talking about, I was doing this work for couple of years). We hoped that those hundreds of hours could be provided by BugZappers, but it didn't happen. Also, should developers spend those hours on cleaning bugzilla so that you will be happy, or should they work on fixing bugs? It is not popular to say, but bugzilla is here not for users, but it is primarily tool for developers to organize their work. And frankly, if developers find it useless, too bad for anybody else. Just saying. Matěj /rant ... the rest of this thread goes to /dev/null for me, except of questions which I can in my opinion usefully comment on. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Retire rubygem-mongrel
Hi, If nobody objects, I am going to retire *rubygem-mongrel* and its associated gems rubygem-gem_plugin, rubygem-fastthread and rubygem-mongrel_cluster. Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 3 available in Fedora, the last supported Ruby on Rails version was 2.3.7. There are available more viable Ruby web servers such as rubygem-thin. I believe nobody will regret this loss. Vit [1] https://github.com/evan/mongrel/commit/12a06f658a5645e8ad0fa41c488a6f4a6508d740 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-URI] Created tag perl-URI-1.59-3.fc17
The lightweight tag 'perl-URI-1.59-3.fc17' was created pointing to: 5d64e5c... Spec clean-up -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File POE-Component-Client-HTTP-0.944.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE-Component-Client-HTTP: 79697fe8bf93bcc85ca7b32a94ca5906 POE-Component-Client-HTTP-0.944.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-Client-HTTP] 0.944 bump
commit 1d961c830b2c6c7da38cc36d9fc032e14acb7cde
Author: Petr Šabata con...@redhat.com
Date: Fri Jan 20 16:36:06 2012 +0100
0.944 bump
.gitignore |1 +
perl-POE-Component-Client-HTTP.spec | 101 --
sources |2 +-
3 files changed, 50 insertions(+), 54 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9c63dd0..6844628 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
POE-Component-Client-HTTP-0.895.tar.gz
+/POE-Component-Client-HTTP-0.944.tar.gz
diff --git a/perl-POE-Component-Client-HTTP.spec
b/perl-POE-Component-Client-HTTP.spec
index a0ffb21..a15e72e 100644
--- a/perl-POE-Component-Client-HTTP.spec
+++ b/perl-POE-Component-Client-HTTP.spec
@@ -5,58 +5,65 @@
# rpmbuild ... --define '_with_network_tests 1' ...
# rpmbuild ... --with network_tests ...
# define _with_network_tests 1 in your ~/.rpmmacros
-#
-# Note that right now, the only way to run tests locally from a cvs sandbox
-# make noarch type scenario is the third one.
Name: perl-POE-Component-Client-HTTP
-Version:0.895
-Release:5%{?dist}
+Version:0.944
+Release:1%{?dist}
Summary:A non-blocking/parallel web requests engine for POE
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/POE-Component-Client-HTTP
Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-HTTP-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
BuildArch: noarch
+BuildRequires: perl(base)
+BuildRequires: perl(constant)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Data::Dumper)
BuildRequires: perl(ExtUtils::MakeMaker)
-# Original perl(POE) = 1.28 rounded to 3 digit precision
-BuildRequires: perl(POE) = 1.280
-BuildRequires: perl(HTTP::Request) = 1.3
-BuildRequires: perl(HTTP::Response) = 1.37
-BuildRequires: perl(URI) = 1.24
-# Original perl(POE::Component::Client::Keepalive) = 0.261 rounded to
+BuildRequires: perl(HTTP::Headers) = 5.810
+BuildRequires: perl(HTTP::Request) = 5.811
+BuildRequires: perl(HTTP::Request::Common) = 5.811
+BuildRequires: perl(HTTP::Response) = 5.813
+BuildRequires: perl(HTTP::Status) = 5.811
+BuildRequires: perl(IO::File)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IO::Socket::INET)
+BuildRequires: perl(Net::HTTP::Methods) = 5.812
+BuildRequires: perl(POE) = 1.312
+# Original perl(POE::Component::Client::Keepalive) = 0.268 rounded to
# 4 digit precision
-BuildRequires: perl(POE::Component::Client::Keepalive) = 0.2610
-
-# tests...
+BuildRequires: perl(POE::Component::Client::Keepalive) = 0.2680
+BuildRequires: perl(POE::Driver::SysRW)
+BuildRequires: perl(POE::Filter)
+BuildRequires: perl(POE::Filter::HTTPChunk)
+BuildRequires: perl(POE::Filter::HTTPHead)
+BuildRequires: perl(POE::Filter::Line)
+BuildRequires: perl(POE::Filter::Stackable)
+BuildRequires: perl(POE::Filter::Stream)
+BuildRequires: perl(POE::Session)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Socket)
+BuildRequires: perl(Socket::GetAddrInfo) = 0.19
+BuildRequires: perl(URI) = 1.37
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
-BuildRequires: perl(Test::More)
-
-# use base...
-Requires: perl(POE::Filter), perl(POE::Filter::Stackable)
-# use POE qw{ ... }
-# Original perl(POE::Component::Client::Keepalive) = 0.261 rounded to
+BuildRequires: perl(Test::POE::Server::TCP) = 1.14
+BuildRequires: perl(Test::More) 0.96
+BuildRequires: perl(Time::HiRes)
+Requires: perl(HTTP::Headers) = 5.810
+Requires: perl(HTTP::Request) = 5.811
+Requires: perl(HTTP::Request::Common) = 5.811
+Requires: perl(HTTP::Response) = 5.813
+Requires: perl(HTTP::Status) = 5.811
+Requires: perl(Net::HTTP::Methods) = 5.812
+Requires: perl(POE) = 1.312
+# Original perl(POE::Component::Client::Keepalive) = 0.268 rounded to
# 4 digit precision
-Requires: perl(POE::Component::Client::Keepalive) = 0.2610
-
+Requires: perl(POE::Component::Client::Keepalive) = 0.2680
+Requires: perl(Socket::GetAddrInfo) = 0.19
+Requires: perl(URI) = 1.37
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
-### auto-added brs!
-BuildRequires: perl(Test::POE::Server::TCP)
-BuildRequires: perl(Net::HTTP::Methods) = 0.02
-
-### auto-added reqs!
-Requires: perl(HTTP::Request) = 1.3
-Requires: perl(HTTP::Response) = 1.37
-Requires: perl(Net::HTTP::Methods) = 0.02
-# Original perl(POE) = 1.28 rounded to 3 digit precision
-Requires: perl(POE) = 1.280
-Requires: perl(URI) = 1.24
-
%{?perl_default_filter}
%description
@@ -64,50 +71,38 @@ POE::Component::Client::HTTP is an HTTP user-agent for POE.
It lets other
sessions run while HTTP transactions are being processed, and it lets several
HTTP
Re: Retire rubygem-mongrel
On Fri, Jan 20, 2012 at 09:27, Vít Ondruch vondr...@redhat.com wrote: Hi, If nobody objects, I am going to retire *rubygem-mongrel* and its associated gems rubygem-gem_plugin, rubygem-fastthread and rubygem-mongrel_cluster. Mongrel is not maintained anymore [1]. It dos not support Ruby on Rails 3 available in Fedora, the last supported Ruby on Rails version was 2.3.7. There are available more viable Ruby web servers such as rubygem-thin. I believe nobody will regret this loss. I believe the rubygem-passenger package that is being worked on for inclusion in fedora still requires rubygem-fastthread. https://bugzilla.redhat.com/show_bug.cgi?id=470696 -greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 781402] perl-POE-Component-Client-HTTP-0.944 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=781402 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-POE-Component-Client-H ||TTP-0.944-1.fc17 Resolution||RAWHIDE Last Closed||2012-01-20 10:51:31 -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On 19 January 2012 23:23, David Tardon dtar...@redhat.com wrote: On Thu, Jan 19, 2012 at 06:50:50PM -0500, Stephen Gallagher wrote: On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: Kevin Fenzi wrote: Keeping packages around with no maintainers or people handling their bugs is poor for everyone. Why? If I, as a user, really need a certain piece of software, I'd rather have an unmaintained package than none at all! Worst case, I can't use the package at all, in which case I'm still no worse off than with no package at all! I disagree. The existence of a package triggers certain assumptions: the package will be maintained and keep working. That's the point of there *being* a package, after all. So if there's a package for something, I don't check for security updates for that 'something' myself. I figure the packager is doing that for me. So if I wind up with an unmaintained package installed, my security has just been reduced. Yes, I agree with this completely. If something is not being maintained in Fedora, it's better to retire it. Then a user who wants that piece of software will have two options: 1) They can build it and maintain it themselves on their own system(s) 2) They can choose to build and maintain it for Fedora by unretiring it. 3) They can choose another distro that contains the package(s). That is not a bad thing though. A) The user will be happier because they have support B) Our developers will be happier because they can focus on what they want to work on C) That distros developers will be happier because they have enough users that want what they are producing. -- Stephen J Smoogen. The core skill of innovators is error recovery, not failure avoidance. Randy Nelson, President of Pixar University. Years ago my mother used to say to me,... Elwood, you must be oh so smart or oh so pleasant. Well, for years I was smart. I recommend pleasant. You may quote me. —James Stewart as Elwood P. Dowd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
Stephen Gallagher (sgall...@redhat.com) said: Essentially, when closing this bug as UPSTREAM, we are communicating to our users This will get fixed. Probably. And it will get pulled into Fedora eventually. Probably. Most people, when they can actually be convinced to file a real bug report (even through ABRT), are doing so because they have an issue with the software and want to know when it's fixed. Closing things upstream requires that the reporters (who already likely had to be coaxed to file a bug in the first place) now also have to manually choose to go and create an account on an unrelated bug tracker if they want to follow along on the resolution of the issue. In some cases, this *is* the most appropriate resolution, though. For example, I get the occasional RFE, or request for a behavior/appearance change, or even for some bugfix that requires rewriting an entire subsystem of a package. In that case, I will likely open up a bug upstream, and close the Fedora bug, because it is really not up to me at all when, or *if*, such a bug gets fixed; as a downstream maintainer, I'm not going to put changes of that sort into Fedora alone, and upstream may very well decide not to do it. For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see why a simple CLOSED-UPSTREAM is wrong. (Unless you'd prefer CLOSED-WONTFIX, as I'm not fixing that myself...) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 20/01/12 16:24, Bill Nottingham wrote: In that case, I will likely open up a bug upstream, and close the Fedora bug, because it is really not up to me at all when, or *if*, such a bug gets fixed; as a downstream maintainer, I'm not going to put changes of that sort into Fedora alone, and upstream may very well decide not to do it. For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see why a simple CLOSED-UPSTREAM is wrong. (Unless you'd prefer CLOSED-WONTFIX, as I'm not fixing that myself...) Bill Maybe Just comment: //* Standard Comment */ bug #123 some.external.place has been opened, Please keep an eye on that bug for progress. Closing this bug CLOSED-UPSTREAM I believe you can look at external trackers, without having to sign up. I just tested with KDE, which is not installed. -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
* Ralf Corsepius [20/01/2012 15:25] : ... and why no simply keep these BZs open and/or to add a note Because the bug isn't open. There's nothing more to do on it in its present state and having it show up in lists of open bugs is counter-productive. This would at least reflect the actual situation in Fedora: Bug is still present. Just like every open bug in upstream's bugtracker that hasn't been reported in brc. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[389-devel] Please review: Remove redundant code - make a global into a static
From 1ddcc951eec9ede74ae6650de04a921198aec493 Mon Sep 17 00:00:00 2001
From: Rich Megginson rmegg...@redhat.com
Date: Fri, 20 Jan 2012 09:52:33 -0700
Subject: [PATCH] Remove redundant code - make a global into a static
Remove redundant code - make a global into a static
---
ldap/servers/plugins/linkedattrs/fixup_task.c |7 ---
ldap/servers/plugins/usn/usn.c|2 +-
2 files changed, 1 insertions(+), 8 deletions(-)
diff --git a/ldap/servers/plugins/linkedattrs/fixup_task.c
b/ldap/servers/plugins/linkedattrs/fixup_task.c
index b1c29d3..a698a6c 100644
--- a/ldap/servers/plugins/linkedattrs/fixup_task.c
+++ b/ldap/servers/plugins/linkedattrs/fixup_task.c
@@ -77,13 +77,6 @@ linked_attrs_fixup_task_add(Slapi_PBlock *pb, Slapi_Entry *e,
goto out;
}
- /* make sure the plugin is not closed */
- if(!linked_attrs_is_started()){
- *returncode = LDAP_OPERATIONS_ERROR;
- rv = SLAPI_DSE_CALLBACK_ERROR;
- goto out;
- }
-
/* get arg(s) */
linkdn = fetch_attr(e, linkdn, 0);
diff --git a/ldap/servers/plugins/usn/usn.c b/ldap/servers/plugins/usn/usn.c
index dbae1d5..faa737c 100644
--- a/ldap/servers/plugins/usn/usn.c
+++ b/ldap/servers/plugins/usn/usn.c
@@ -68,7 +68,7 @@ static int usn_get_attr(Slapi_PBlock *pb, const char* type,
void *value);
static int usn_rootdse_search(Slapi_PBlock *pb, Slapi_Entry* e,
Slapi_Entry* entryAfter, int *returncode, char *returntext, void *arg);
-int g_plugin_started = 0;
+static int g_plugin_started = 0;
/*
* Register USN plugin
* Note: USN counter initialization is done in the backend (ldbm_usn_init).
--
1.7.1
--
389-devel mailing list
389-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Package categorization and distribution construction
On Thu, Jan 19, 2012 at 11:48:38AM -0500, Przemek Klosowski wrote: On 01/19/2012 10:43 AM, Richard W.M. Jones wrote: I wrote a little graphical tool called rpmdepsize (it's in Fedora) which may be useful. Unfortunately it only works with a single package, eg: rpmdepsize kernel Interesting--but I tried it on my F15 box and it froze. I tried 'rpdepsize kernel' and on a very simple (no deps) package 'setup': it prints an error: (rpmdepsize:18625): LablGTK-CRITICAL **: GSourceFunc: callback raised an exception and just sits there with gray screen and message 'Loading kernel ...' It runs 'yum' at this point, so it's likely that yum is just being slow. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 11:24 -0500, Bill Nottingham wrote: Stephen Gallagher (sgall...@redhat.com) said: Essentially, when closing this bug as UPSTREAM, we are communicating to our users This will get fixed. Probably. And it will get pulled into Fedora eventually. Probably. Most people, when they can actually be convinced to file a real bug report (even through ABRT), are doing so because they have an issue with the software and want to know when it's fixed. Closing things upstream requires that the reporters (who already likely had to be coaxed to file a bug in the first place) now also have to manually choose to go and create an account on an unrelated bug tracker if they want to follow along on the resolution of the issue. In some cases, this *is* the most appropriate resolution, though. For example, I get the occasional RFE, or request for a behavior/appearance change, or even for some bugfix that requires rewriting an entire subsystem of a package. In that case, I will likely open up a bug upstream, and close the Fedora bug, because it is really not up to me at all when, or *if*, such a bug gets fixed; as a downstream maintainer, I'm not going to put changes of that sort into Fedora alone, and upstream may very well decide not to do it. For the hypothetical bug I might get of 'port GnuCash to GTK 3', I don't see why a simple CLOSED-UPSTREAM is wrong. (Unless you'd prefer CLOSED-WONTFIX, as I'm not fixing that myself...) I'm suggesting that I'd prefer opening the bug upstream, setting this bug to ASSIGNED and then waiting to see what happens upstream. If upstream says they won't fix it, close it WONTFIX. If upstream is going to fix it, leave it open until a Fedora package is available that does fix it, then you can list it in the Bodhi update. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [389-devel] Please review: Remove redundant code - make a global into a static
Rich Megginson wrote: -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel ack. -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Rawhide tree structure
Did my eyes deceive me, or do the packages now get separated and put in their respected dir of their first letter, and not located in one dir now? Did the tree change or is this an error? -- Mike Chambers Madisonville, KY Best little town on Earth! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On 01/20/2012 05:55 PM, Emmanuel Seyman wrote: * Ralf Corsepius [20/01/2012 15:25] : ... and why no simply keep these BZs open and/or to add a note Because the bug isn't open. Surely the bug is open: The product you are supposed to be responsible for (A Fedora package) suffers from an unfixed bug, documented in bugzilla. There's nothing more to do on it in its present state Surely, there are things to be done. - Others might be able to fix it. - You can cross check if its fixed in the next upstream release and having it show up in lists of open bugs is counter-productive This logic escapes me - A reporter has reported a bug in your package and has are informed you about, so you know about it. All you are doing by closing is to switch off a semi-automated checklist you'd better off checking your package for (== QA) when modifying/updating it. Yes, this means effort, but it should be part of a packager's QA routine. People not doing so work careless. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide tree structure
MC == Mike Chambers m...@miketc.net writes: MC Did my eyes deceive me, or do the packages now get separated and put MC in their respected dir of their first letter, and not located in one MC dir now? Yes. MC Did the tree change or is this an error? The tree changed. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[SPAM] Re: Rawhide tree structure
On Fri, 20 Jan 2012 11:44:54 -0600 Mike Chambers m...@miketc.net wrote: Did my eyes deceive me, or do the packages now get separated and put in their respected dir of their first letter, and not located in one dir now? Did the tree change or is this an error? This did happen and it is not an error. It was an intentional change since many web browsers and web servers do not cope well with 17K entries in a single directory. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for update to packaging guidelines for icon files
Adam Williamson wrote: Would it make sense just to put the hicolor directory into filesystem? It seems silly to have every single graphical app in the distro depend on a package simply for the provision of the directory... There are also all the subdirectories such as /usr/share/icons/hicolor/24x24/apps/. And the whole purpose of hicolor-icon-theme is to include those directories and the index.theme file. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package categorization and distribution construction
Bill Nottingham wrote: These could be separate groups, (i.e., XFCE's 'Office Suite' group may not have LibreOffice). So there would be the ability to customize that. Yes, that makes sense. Right now, if you enable Sound and Video, you get Totem forced in (and with it, plenty of GNOME dependencies such as Tracker) even if you chose only the KDE Plasma Workspaces instead of GNOME. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PHP 5.4 Fedora 17 feature - STATUS
Le 19/01/2012 19:57, Remi Collet a écrit : Feature page : https://fedoraproject.org/wiki/Features/Php54 I just finish to rebuild php-5.4.0-0.1.RC6.fc17 And dependant packages : cups-1.5.0-28.fc17 graphviz-2.28.0-13.fc17 libdigidocpp-0.3.0-13.fc17 libpuzzle-0.11-12.fc17 php-facedetect-1.0.1-6.fc17 php-idn-1.2c-5.fc17 php-libvirt-0.4.5-1.fc17 php-magickwand-1.0.9-2.fc17 php-pecl-apc-3.1.9-4.svn316786.fc17 php-pecl-gearman-1.0.1-1.fc17 php-pecl-geoip-1.0.8-1.fc17 php-pecl-gmagick-1.0.10-0.1.b1.fc17 php-pecl-igbinary-1.1.2-0.1.git3b8ab7e.fc17 php-pecl-lzf-1.5.2-9.fc17 php-pecl-mailparse-2.1.5-6.fc17 php-pecl-imagick-3.1.0-0.1.RC1.fc17 php-pecl-memcache-3.0.6-3.fc17 php-pecl-memcached-2.0.0-0.1.git1736623.fc17 php-pecl-mongo-1.2.7-1.fc17 php-pecl-ncurses-1.0.1-5.fc17 php-pecl-oauth-1.2.2-3.fc17 php-pecl-radius-1.2.5-13.fc17 php-pecl-rrd-1.0.5-3.fc17 php-pecl-selinux-0.3.1-8.fc17 php-pecl-solr-1.0.2-3.fc17 php-pecl-sphinx-1.1.0-3.fc17 php-pecl-ssh2-0.11.3-1.fc17 php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17 php-pecl-yaml-1.0.1-6.fc17 php-shout-0.9.2-10.fc17 syck-0.61-16.fc17 uuid-1.6.2-8.fc17 zarafa-7.0.4-2.fc17 zorba-2.1.0-3.fc17 Pending ice (owner will take care of it) maniadrive (tomorrow...) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Math-Round] Spec clean-up
commit 528d46467717c60ac5c1ccd32752eedeed9ee4b9
Author: Paul Howarth p...@city-fan.org
Date: Fri Jan 20 19:11:36 2012 +
Spec clean-up
- BR: perl(Exporter) and perl(POSIX)
- Make %files list more specific
- Don't use macros for commands
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Recode README as UTF-8
.gitignore |2 +-
Math-Round-0.06-utf8.patch | 11 +
perl-Math-Round.spec | 54 +++
3 files changed, 41 insertions(+), 26 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7a51b5d..d7bb130 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Math-Round-0.06.tar.gz
+/Math-Round-[0-9.]*.tar.gz
diff --git a/Math-Round-0.06-utf8.patch b/Math-Round-0.06-utf8.patch
new file mode 100644
index 000..be1cd2c
--- /dev/null
+++ b/Math-Round-0.06-utf8.patch
@@ -0,0 +1,11 @@
+--- Math-Round-0.06/README
Math-Round-0.06/README
+@@ -37,7 +37,7 @@
+ make install
+
+
+-Copyright � 2002 Geoffrey Rommel. All rights reserved.
++Copyright © 2002 Geoffrey Rommel. All rights reserved.
+ This program is free software; you can redistribute it and/or modify
+ it under the same terms as Perl itself.
+
diff --git a/perl-Math-Round.spec b/perl-Math-Round.spec
index acc8c92..024ea15 100644
--- a/perl-Math-Round.spec
+++ b/perl-Math-Round.spec
@@ -1,61 +1,65 @@
Name: perl-Math-Round
-Version:0.06
-Release:11%{?dist}
+Version:0.06
+Release:12%{?dist}
Summary:Perl extension for rounding numbers
-
Group: Development/Libraries
-License:GPL+ or Artistic
-URL:http://search.cpan.org/dist/Math-Round
-Source0:
http://search.cpan.org/CPAN/authors/id/G/GR/GROMMEL/Math-Round-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-
-BuildArch: noarch
+License:GPL+ or Artistic
+URL:http://search.cpan.org/dist/Math-Round
+Source0:
http://search.cpan.org/CPAN/authors/id/G/GR/GROMMEL/Math-Round-%{version}.tar.gz
+Patch0: Math-Round-0.06-utf8.patch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch: noarch
+BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+BuildRequires: perl(POSIX)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
Math::Round supplies functions that will round numbers in different ways. The
functions round and nearest are exported by default; others are available as
described below. use ... qw(:all) exports all functions.
-
%prep
%setup -q -n Math-Round-%{version}
+# Recode docs as UTF-8
+%patch0 -p1
+
# remove errant execute bits
-find . -type f -exec chmod -x {} ';'
+find . -type f -exec chmod -c -x {} ';'
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
rm -rf %{buildroot}
-
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
-
-%{_fixperms} %{buildroot}/*
-
+%{_fixperms} %{buildroot}
%check
make test
-
%clean
rm -rf %{buildroot}
-
%files
%defattr(-,root,root,-)
%doc Changes README
-%{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
-
+%{perl_vendorlib}/auto/Math/
+%{perl_vendorlib}/Math/
+%{_mandir}/man3/Math::Round.3pm*
%changelog
+* Fri Jan 20 2012 Paul Howarth p...@city-fan.org - 0.06-12
+- BR: perl(Exporter) and perl(POSIX)
+- Make %%files list more specific
+- Don't use macros for commands
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Recode README as UTF-8
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.06-11
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
@@ -69,7 +73,7 @@ rm -rf %{buildroot}
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Mon Dec 20 2010 Marcela Maslanova mmasl...@redhat.com - 0.06-7
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Mon May 03 2010 Marcela Maslanova mmasl...@redhat.com - 0.06-6
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: PHP 5.4 Fedora 17 feature - STATUS
On Fri, Jan 20, 2012 at 4:51 PM, Remi Collet fed...@famillecollet.com wrote: Le 19/01/2012 19:57, Remi Collet a écrit : Feature page : https://fedoraproject.org/wiki/Features/Php54 I just finish to rebuild php-5.4.0-0.1.RC6.fc17 And dependant packages : cups-1.5.0-28.fc17 graphviz-2.28.0-13.fc17 libdigidocpp-0.3.0-13.fc17 libpuzzle-0.11-12.fc17 php-facedetect-1.0.1-6.fc17 php-idn-1.2c-5.fc17 php-libvirt-0.4.5-1.fc17 php-magickwand-1.0.9-2.fc17 php-pecl-apc-3.1.9-4.svn316786.fc17 php-pecl-gearman-1.0.1-1.fc17 php-pecl-geoip-1.0.8-1.fc17 php-pecl-gmagick-1.0.10-0.1.b1.fc17 php-pecl-igbinary-1.1.2-0.1.git3b8ab7e.fc17 php-pecl-lzf-1.5.2-9.fc17 php-pecl-mailparse-2.1.5-6.fc17 php-pecl-imagick-3.1.0-0.1.RC1.fc17 php-pecl-memcache-3.0.6-3.fc17 php-pecl-memcached-2.0.0-0.1.git1736623.fc17 php-pecl-mongo-1.2.7-1.fc17 php-pecl-ncurses-1.0.1-5.fc17 php-pecl-oauth-1.2.2-3.fc17 php-pecl-radius-1.2.5-13.fc17 php-pecl-rrd-1.0.5-3.fc17 php-pecl-selinux-0.3.1-8.fc17 php-pecl-solr-1.0.2-3.fc17 php-pecl-sphinx-1.1.0-3.fc17 php-pecl-ssh2-0.11.3-1.fc17 php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17 php-pecl-yaml-1.0.1-6.fc17 php-shout-0.9.2-10.fc17 syck-0.61-16.fc17 uuid-1.6.2-8.fc17 zarafa-7.0.4-2.fc17 zorba-2.1.0-3.fc17 very nice, thanks for great job and for fixing php-pecl-ssh2 -- Itamar Reis Peixoto msn, google talk: ita...@ispbrasil.com.br +55 11 4063 5033 (FIXO SP) +55 34 9158 9329 (TIM) +55 34 8806 3989 (OI) +55 34 3221 8599 (FIXO MG) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Math-Round] Created tag perl-Math-Round-0.06-12.fc17
The lightweight tag 'perl-Math-Round-0.06-12.fc17' was created pointing to: 528d464... Spec clean-up -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: PHP 5.4 Fedora 17 feature - STATUS
Am 20.01.2012 19:51, schrieb Remi Collet: Le 19/01/2012 19:57, Remi Collet a écrit : Feature page : https://fedoraproject.org/wiki/Features/Php54 I just finish to rebuild php-5.4.0-0.1.RC6.fc17 And dependant packages : php-facedetect-1.0.1-6.fc17 php-idn-1.2c-5.fc17 php-libvirt-0.4.5-1.fc17 php-magickwand-1.0.9-2.fc17 php-pecl-apc-3.1.9-4.svn316786.fc17 php-pecl-geoip-1.0.8-1.fc17 php-pecl-mailparse-2.1.5-6.fc17 php-pecl-imagick-3.1.0-0.1.RC1.fc17 php-pecl-ssh2-0.11.3-1.fc17 php-pecl-xdebug-2.2.0-0.1.gitd076740.fc17 thank you for your great work, especially patches for PHP/MySQL on recent fedora-versions or recent PHP/MySQL packages on older fedora-releases in your private repo all over the last years this is a great base for normal users as also for people like me building core-services in recent versions for fedora version-1 on own environments! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
* Ralf Corsepius [20/01/2012 19:53] : Surely the bug is open: The product you are supposed to be responsible for (A Fedora package) suffers from an unfixed bug, documented in bugzilla. Anyone looking in brc for the unfixed bugs of a package is going to be severely disappointed. Bugs there will only be a minute of the bugs the upstream bugtracker contains. If you're looking for this type of information, using anything but upstream's bugtracker is a waste of time. Surely, there are things to be done. - Others might be able to fix it. - You can cross check if its fixed in the next upstream release In both cases, it make more sense to do this work in upstream's context rather than a Fedora context. Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: PHP 5.4 Fedora 17 feature - STATUS
Le 20/01/2012 19:51, Remi Collet a écrit : Pending ice (owner will take care of it) Done, thanks for your help on ice-php ! best regards, H. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for update to packaging guidelines for icon files
Adam Williamson wrote: Would it make sense just to put the hicolor directory into filesystem? It seems silly to have every single graphical app in the distro depend on a package simply for the provision of the directory... I agree. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning blam: RSS feed reader
Don't currently use, don't have time to maintain it, feel free to take it (I kept myself as co-maintainer to help out the transition): https://admin.fedoraproject.org/pkgdb/acls/name/blam -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bundled part of code
19.01.2012 17:03, Kevin Kofler wrote: Pavel Alexeev wrote: But how I should then deal with licensing in my situation if its mismatch? There is no mismatch, it's OK to include GPLv2+ code in a GPLv3+ program, the result is just GPLv3+. (You can also declare License: GPLv3+ and GPLv2+, but if everything is getting linked into a single binary, what's left is really just GPLv3+.) Thank you very much for clarification! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Changes coming for CUPS 1.6
On Fri, 2012-01-20 at 09:25 +, Tim Waugh wrote: On Thu, 2012-01-19 at 15:50 -0800, Adam Williamson wrote: What a great idea! We could call one of them 'Postscript'... Not likely. :-) I think the current candidate for the optional vector format is PDF 1.4/1.5. Everything old is new again... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposal for update to packaging guidelines for icon files
Kevin Kofler wrote: Adam Williamson wrote: Would it make sense just to put the hicolor directory into filesystem? It seems silly to have every single graphical app in the distro depend on a package simply for the provision of the directory... There are also all the subdirectories such as /usr/share/icons/hicolor/24x24/apps/. And the whole purpose of hicolor-icon-theme is to include those directories and the index.theme file. I count two files and 339 directories (plus one directory and three file under /usr/share/doc/). If that's not enough to justify a separate package, but it's undesirable to include these files even on a minimal server, then perhaps they could be added to some X package that all graphical programs depend on anyway? Just a thought. Björn Persson signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Too much bureaucracy or not enough interest? (Re: [ACTION REQUIRED] Retiring packages for F-17)
On Tue, 17 Jan 2012 02:20:15 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Kevin Fenzi wrote: We talked about, but never finished implementing a timeout on acl requests. The way this would work is that maintainer would have some time.. 3 weeks or something to reject a acl request. If they did not do so, pkgdb would automatically approve it at the end of the time. This would help in cases where the maintainer is overloaded or not paying attention. The question is of course why we need to allow the maintainer to reject comaintainership in the first place. Sure. In an ideal world we never would. In the real world it might be that someone is a new maintainer and wanting to work on a package that is very complex or sensitive without much background, or someone who the current maintainers know they differ on philosophy or something that would make working together difficult, or a maintainer who doesn't get along with upstream and would cause undue friction, or a maintainer who doesn't communicate with existing maintainers well, etc. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Thu, 19 Jan 2012 18:50:50 -0500 Stephen Gallagher sgall...@redhat.com wrote: On Thu, 2012-01-19 at 15:30 -0800, Adam Williamson wrote: On Sat, 2012-01-14 at 19:12 +0100, Kevin Kofler wrote: ...snip... (And now with my packager hat on, fixing and/or updating a package in the repo also requires less effort than unretiring a package which got removed.) This is an important point: I think it would be much less of a problem to retire packages if the process for unretiring them were not so painful. I _do_ think the unretiring process is an excellent example of unnecessary bureaucracy (as is the renaming process, good lord, what a PITA). Those two things could stand to be trimmed down. At least to 'if you're a provenpackager (or even just a sponsored packager) you can unretire a package without any obstacles'. If you file a FESCo ticket to change this policy, this approach would have my support. There's no reason that a package rename or unretirement should need to go through a full review (although as I said in an earlier email, the side-effect here is that such things can help curb specrot). There are two cases here: a) rename The changes involved in a rename are pretty minor. Just usually adding Obsoletes and Provides and changing the name in the spec file. That said, it's amazing how easy it is to get this wrong. It happens ALL THE TIME. ;) having a review to get another pair of eyes was decided to be the best way to avoid that. I tried (and failed) to get a lower bar for this. Perhaps current fesco would be interested. b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Once upon a time, Kevin Fenzi ke...@scrye.com said: b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
On Fri, 20 Jan 2012 17:15:57 -0600 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Kevin Fenzi ke...@scrye.com said: b) unretirement This could be pretty massive changes. If something was retired years ago, the entire spec could be very different. Or it could have been yesterday. But making the time variable for re-review makes it much more complex. Last time we looked at this, it was an easy way to tell if something needed re-review. Is it orphaned? then just take it. Is it retired? then re-review it. I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). Possibly, but that info isn't super easy to find. You would need to look at the scm-commits list to see when it was retired. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Requesting a change to the BugStatusWorkFlow: Closed/UPSTREAM
On Fri, 2012-01-20 at 09:30 +, Tim Waugh wrote: On Fri, 2012-01-20 at 08:39 +0100, Marcela Mašláňová wrote: I use closed/upstream, when I already fixed it in upstream. This bug should be closed with number of release, where it is fixed or with the link to the commit. I wouldn't blame this state for not fixing bug in some projects. I guess instead of closed/upstream we would see more closed/wontfix|cantfix. I use POST for that. A patch or solution believed to resolve this matter has been proposed (POSTed) for inclusion in the package or kernel. For non-kernel packages I read that as meaning that the patch is in-hand upstream, and not yet built in Fedora. POST is kind of problematic as different groups use it for different meanings. anaconda use it to mean 'a patch has been sent to anaconda-devel-list for review', for e.g. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: An Easy But Serious Screensaver Security Problem In X.Org
On Fri, 2012-01-20 at 10:11 -0500, Neal Becker wrote: Hopefully this is being addressed: http://www.phoronix.com/scan.php?page=news_itempx=MTA0NTA It was fixed in Fedora 16 and Rawhide (the only releases it actually affected) before Phoronix even posted their 'update', they just missed the update. https://admin.fedoraproject.org/updates/FEDORA-2012-0712/xkeyboard-config-2.3-3.fc16 Was submitted 2012-01-19 07:08:19 and pushed stable 2012-01-19 22:01:39. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
mdadm: sending ioctl 1261 to a partition!
[root@srv-rhsoft:~]$ dmesg -c mdadm: sending ioctl 1261 to a partition! mdadm: sending ioctl 1261 to a partition! what does the system want to tell me with this each time /sbin/mdadm --detail is called to any raid-array? can this be ignored or is there a possible bug in recent kernel/mdadm which should be reported in bugzilla? mdadm-3.2.3-3 [root@srv-rhsoft:~]$ uname -r 2.6.41.10-2.fc15.x86_64 #1 SMP Thu Jan 19 02:27:37 UTC 2012 ___ [root@srv-rhsoft:~]$ cat /proc/mdstat Personalities : [raid1] [raid10] md2 : active raid10 sdc3[0] sdd3[3] sda3[4] sdb3[5] 3875222528 blocks super 1.1 512K chunks 2 near-copies [4/4] [] bitmap: 0/29 pages [0KB], 65536KB chunk md1 : active raid10 sdc2[0] sdd2[3] sda2[4] sdb2[5] 30716928 blocks super 1.1 512K chunks 2 near-copies [4/4] [] bitmap: 1/1 pages [4KB], 65536KB chunk md0 : active raid1 sdc1[0] sdd1[3] sda1[4] sdb1[5] 511988 blocks super 1.0 [4/4] [] unused devices: none ___ [root@srv-rhsoft:~]$ /sbin/mdadm --detail /dev/md1 /dev/md1: Version : 1.1 Creation Time : Wed Jun 8 13:10:52 2011 Raid Level : raid10 Array Size : 30716928 (29.29 GiB 31.45 GB) Used Dev Size : 15358464 (14.65 GiB 15.73 GB) Raid Devices : 4 Total Devices : 4 Persistence : Superblock is persistent Intent Bitmap : Internal Update Time : Sat Jan 21 03:59:22 2012 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : near=2 Chunk Size : 512K Name : localhost.localdomain:1 UUID : b7475879:c95d9a47:c5043c02:0c5ae720 Events : 10563 Number Major Minor RaidDevice State 0 8 340 active sync /dev/sdc2 5 8 181 active sync /dev/sdb2 4 822 active sync /dev/sda2 3 8 503 active sync /dev/sdd2 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for F-17
Once upon a time, Kevin Fenzi ke...@scrye.com said: On Fri, 20 Jan 2012 17:15:57 -0600 Chris Adams cmad...@hiwaay.net wrote: I would think that making it release based rather than time based should be okay. If there have been N released shipped without package foo, then foo needs to be re-reviewed (with N being only 1 or 2). Possibly, but that info isn't super easy to find. You would need to look at the scm-commits list to see when it was retired. If it was release-1 or release-2, those are both current and still getting updates; checking the current trees on a mirror would show if the package was in either release. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-01-23 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-01-23 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again. We have a bunch of action items from last week to catch up on, and now Fedora 17 testing is starting to come online, with RATS runs and the first blocker bug review meeting next Friday. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120123 The current proposed agenda is include below. If no topics beyond the standard Previous meeting follow-up and AutoQA update topics are present or proposed, the meeting will be canceled. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Requested change to BugStatusWorkFlow 3. Upcoming QA events 4. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Data-OptList] Spec clean-up
commit 9b6ccf963cfbe31950031ed69a3a77f49e8b5641
Author: Paul Howarth p...@city-fan.org
Date: Fri Jan 20 10:43:17 2012 +
Spec clean-up
- drop -tests subpackage (general lack of interest in this), but include
them as documentation for the main package
- drop redundant %{?perl_default_filter}
- don't use macros for commands
- can't find any dependency cycle so drop %{?perl_bootstrap} usage
- drop ExtUtils::MakeMaker version requirement to 6.30, actual working
minimum
perl-Data-OptList.spec | 31 ---
1 files changed, 16 insertions(+), 15 deletions(-)
---
diff --git a/perl-Data-OptList.spec b/perl-Data-OptList.spec
index 9abc20a..6f4d1f5 100644
--- a/perl-Data-OptList.spec
+++ b/perl-Data-OptList.spec
@@ -1,25 +1,19 @@
Name: perl-Data-OptList
Summary:Parse and validate simple name/value option pairs
Version:0.107
-Release:3%{?dist}
+Release:4%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Data-OptList-%{version}.tar.gz
URL:http://search.cpan.org/dist/Data-OptList/
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/Data-OptList-%{version}.tar.gz
BuildArch: noarch
-
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
BuildRequires: perl(List::Util)
BuildRequires: perl(Params::Util)
BuildRequires: perl(Sub::Install) = 0.921
BuildRequires: perl(Test::More)
-%if !%{defined perl_bootstrap}
BuildRequires: perl(Test::Pod)
-%endif
-
-%{?perl_default_filter}
-%{?perl_default_subpackage_tests}
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
Hashes are great for storing named data, but if you want more than one entry
@@ -47,25 +41,32 @@ following a name is its value.
%setup -q -n Data-OptList-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
-
find %{buildroot} -type f -name .packlist -exec rm -f {} \;
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+find %{buildroot} -depth -type d -exec rmdir {} \; 2/dev/null
%{_fixperms} %{buildroot}
%check
make test RELEASE_TESTING=1
%files
-%doc Changes LICENSE README
+%doc Changes LICENSE README t/
%{perl_vendorlib}/Data/
%{_mandir}/man3/Data::OptList.3pm*
%changelog
+* Fri Jan 20 2012 Paul Howarth p...@city-fan.org - 0.107-4
+- drop -tests subpackage (general lack of interest in this), but include
+ them as documentation for the main package
+- drop redundant %%{?perl_default_filter}
+- don't use macros for commands
+- can't find any dependency cycle so drop %%{?perl_bootstrap} usage
+- drop ExtUtils::MakeMaker version requirement to 6.30, actual working minimum
+
* Wed Jan 11 2012 Paul Howarth p...@city-fan.org - 0.107-3
- package LICENSE file
- run test suite even when bootstrapping, as it should still pass
@@ -85,7 +86,7 @@ make test RELEASE_TESTING=1
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.106-3
-- 661697 rebuild for fixing problems with vendorach/lib
+- rebuild to fix problems with vendorarch/lib (#661697)
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.106-2
- Mass rebuild with perl-5.12.0
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 783426] New: perl-Gtk2-1.242 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Gtk2-1.242 is available https://bugzilla.redhat.com/show_bug.cgi?id=783426 Summary: perl-Gtk2-1.242 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-Gtk2 AssignedTo: tcall...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Latest upstream release: 1.242 Current version in Fedora Rawhide: 1.241 URL: http://search.cpan.org/dist/Gtk2/ 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 -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 746941] perl-Mojolicious-2.45 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=746941 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-Mojolicious-2.44 is|perl-Mojolicious-2.45 is |available |available --- Comment #32 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org 2012-01-20 06:35:48 EST --- Latest upstream release: 2.45 Current version in Fedora Rawhide: 2.44 URL: http://search.cpan.org/dist/Mojolicious/ 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 -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bot-BasicBot
perl-Bot-BasicBot has broken dependencies in the rawhide tree: On x86_64: perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title) perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple) On i386: perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title) perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Bot-BasicBot
On Fri, Jan 20, 2012 at 01:34:49AM +, build...@fedoraproject.org wrote: perl-Bot-BasicBot has broken dependencies in the rawhide tree: On x86_64: perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title) perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple) On i386: perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title) perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple) Please resolve this as soon as possible. Seems like yet another rpmbuild bug to me... https://bugzilla.redhat.com/show_bug.cgi?id=783442 -P pgp3xL52c3zsN.pgp Description: PGP signature -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 781396] perl-Math-Random-MT-Auto-6.17 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=781396 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Math-Random-MT-Auto-6. ||17-1.fc17 Resolution||RAWHIDE Last Closed||2012-01-20 08:11:03 -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Bot-BasicBot
On 01/20/2012 01:39 PM, Petr Šabata wrote:
On Fri, Jan 20, 2012 at 01:34:49AM +, build...@fedoraproject.org wrote:
perl-Bot-BasicBot has broken dependencies in the rawhide tree:
On x86_64:
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title)
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple)
On i386:
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title)
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple)
Please resolve this as soon as possible.
Seems like yet another rpmbuild bug to me...
https://bugzilla.redhat.com/show_bug.cgi?id=783442
Adding
%{?perl_default_filter}
to your spec fixes this.
Seems to me as if %{?perl_default_filter} is (still) mandatorily required.
Ralf
PS: rpm still seems to be parsing comments.
Adding
# %{?perl_default_filter}
also causes the examples to be filtered out.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Broken dependencies: perl-Bot-BasicBot
On Fri, Jan 20, 2012 at 02:52:38PM +0100, Ralf Corsepius wrote:
On 01/20/2012 01:39 PM, Petr Šabata wrote:
On Fri, Jan 20, 2012 at 01:34:49AM +, build...@fedoraproject.org wrote:
perl-Bot-BasicBot has broken dependencies in the rawhide tree:
On x86_64:
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title)
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple)
On i386:
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Title)
perl-Bot-BasicBot-0.87-2.fc17.noarch requires perl(URI::Find::Simple)
Please resolve this as soon as possible.
Seems like yet another rpmbuild bug to me...
https://bugzilla.redhat.com/show_bug.cgi?id=783442
Adding
%{?perl_default_filter}
to your spec fixes this.
Seems to me as if %{?perl_default_filter} is (still) mandatorily required.
Ralf
PS: rpm still seems to be parsing comments.
Adding
# %{?perl_default_filter}
also causes the examples to be filtered out.
It is more like an rpmbuild regression since the old build
didn't suffer from this nonsense.
Thanks for the tip, though. I'll add this if rpm won't get
fixed soon.
-P
pgpoY1E6qhq1G.pgp
Description: PGP signature
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Business-ISBN-Data] Spec clean-up
commit fd308c3b76e1a32eab0c1875148b0d6b4c6edef8
Author: Paul Howarth p...@city-fan.org
Date: Fri Jan 20 14:16:59 2012 +
Spec clean-up
- Clean up for modern rpmbuild:
- Drop BuildRoot specification
- Drop %clean section
- Don't bother cleaning buildroot in %install section
- Make %files list more explicit
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Use %{_fixperms} macro rather than our own chmod incantation
- Replace provides filter with version that works with rpm ≥ 4.9
- Include tests as %doc since they're referred to by examples/README
.gitignore |2 +-
perl-Business-ISBN-Data.spec | 60 -
2 files changed, 25 insertions(+), 37 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 5916175..31b93b8 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Business-ISBN-Data-20081208.tar.gz
+/Business-ISBN-Data-[0-9.]*.tar.gz
diff --git a/perl-Business-ISBN-Data.spec b/perl-Business-ISBN-Data.spec
index 401dc24..bed6aa7 100644
--- a/perl-Business-ISBN-Data.spec
+++ b/perl-Business-ISBN-Data.spec
@@ -1,72 +1,60 @@
Name: perl-Business-ISBN-Data
Version:20081208
-Release:7%{?dist}
+Release:8%{?dist}
Summary:The data pack for Business::ISBN
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Business-ISBN-Data/
Source0:
http://search.cpan.org/CPAN/authors/id/B/BD/BDFOY/Business-ISBN-Data-%{version}.tar.gz
-BuildRoot: %(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XX)
-
BuildArch: noarch
-
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(Test::Prereq)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+# Remove bogus provide of perl(Business::ISBN)
+%global __provides_exclude ^perl\\(Business::ISBN\\)$
%description
This is a data pack for Business::ISBN. You can update
the ISBN data without changing the version of Business::ISBN.
Most of the interesting stuff is in Business::ISBN.
-
%prep
%setup -q -n Business-ISBN-Data-%{version}
-# Filter unwanted Provides:
-cat \EOF %{name}-prov
-#!/bin/sh
-%{__perl_provides} $* |\
- sed -e '/perl(Business::ISBN)/d'
-EOF
-
-%define __perl_provides %{_builddir}/Business-ISBN-Data-%{version}/%{name}-prov
-chmod +x %{__perl_provides}
-
-
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
-
%install
-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 ';'
-chmod -R u+w $RPM_BUILD_ROOT/*
-
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+find %{buildroot} -depth -type d -exec rmdir {} ';' 2/dev/null
+%{_fixperms} %{buildroot}
%check
make test
-
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
-%defattr(-,root,root,-)
-%doc Changes README LICENSE examples/
-%{perl_vendorlib}/*
-%{_mandir}/man3/*.3*
-
+%doc Changes README LICENSE examples/ t/
+%{perl_vendorlib}/Business/
+%{_mandir}/man3/Business::ISBN::Data.3*
%changelog
+* Fri Jan 20 2012 Paul Howarth p...@city-fan.org - 20081208-8
+- Clean up for modern rpmbuild:
+ - Drop BuildRoot specification
+ - Drop %%clean section
+ - Don't bother cleaning buildroot in %%install section
+ - Make %%files list more explicit
+ - Use DESTDIR rather than PERL_INSTALL_ROOT
+ - Use %%{_fixperms} macro rather than our own chmod incantation
+ - Replace provides filter with version that works with rpm ≥ 4.9
+- Include tests as %%doc since they're referred to by examples/README
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 20081208-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 781402] perl-POE-Component-Client-HTTP-0.944 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=781402 Bug 781402 depends on bug 783149, which changed state. Bug 783149 Summary: Review Request: perl-POE-Component-Resolver - Non-blocking getaddrinfo() resolver https://bugzilla.redhat.com/show_bug.cgi?id=783149 What|Old Value |New Value Resolution||RAWHIDE Status|ASSIGNED|CLOSED -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 226283] Merge Review: perl-URI
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=226283 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC||ppi...@redhat.com Flag||fedora-cvs? --- Comment #9 from Petr Pisar ppi...@redhat.com 2012-01-20 09:44:05 EST --- Package Change Request == Package Name: perl-URI Branches: f15 f16 Owners: InitialCC: perl-sig Please add perl-sig user with watch* permissions only to all Fedora branches. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 783468] New: missing dependancy on perl-Email-Simple-Creator
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: missing dependancy on perl-Email-Simple-Creator https://bugzilla.redhat.com/show_bug.cgi?id=783468 Summary: missing dependancy on perl-Email-Simple-Creator Product: Fedora EPEL Version: el5 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-Email-MIME-Creator AssignedTo: tcall...@redhat.com ReportedBy: carl.johnst...@onthebeach.co.uk QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Description of problem: The perl-Email-MIME-Creator package has a missing dependency on Email::Simple::Creator / perl-Email-Simple-Creator Version-Release number of selected component (if applicable): perl-Email-MIME-Creator.noarch 0:1.453-2.el5 -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 226283] Merge Review: perl-URI
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=226283 --- Comment #10 from Jon Ciesla limburg...@gmail.com 2012-01-20 09:54:58 EST --- Done. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File POE-Component-Client-Keepalive-0.268.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-POE-Component-Client-Keepalive: 318f18fce0837004fac8b792c5bbba1e POE-Component-Client-Keepalive-0.268.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-Client-Keepalive] 0.268 bump
commit 3b944be950efa64c8bf5e8963f4a6486fc59522b
Author: Petr Šabata con...@redhat.com
Date: Fri Jan 20 16:02:28 2012 +0100
0.268 bump
.gitignore |1 +
perl-POE-Component-Client-Keepalive.spec | 50 +++--
sources |2 +-
3 files changed, 28 insertions(+), 25 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6f8e16b..be5a289 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
POE-Component-Client-Keepalive-0.262.tar.gz
+/POE-Component-Client-Keepalive-0.268.tar.gz
diff --git a/perl-POE-Component-Client-Keepalive.spec
b/perl-POE-Component-Client-Keepalive.spec
index 2b97c3a..85894e3 100644
--- a/perl-POE-Component-Client-Keepalive.spec
+++ b/perl-POE-Component-Client-Keepalive.spec
@@ -1,37 +1,37 @@
Name: perl-POE-Component-Client-Keepalive
-%define real_ver 0.262
+%define real_ver 0.268
# Keep four digits to stay above the unfortunate 0.0901,
# so that epoch need not be changed.
Version:%{real_ver}0
-Release:5%{?dist}
+Release:1%{?dist}
Summary:Manages and keeps alive client connections
-
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/POE-Component-Client-Keepalive
Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-Keepalive-%{real_ver}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
-
# core
+BuildRequires: perl(constant)
+BuildRequires: perl(Carp)
BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Test::More)
-# Original perl(POE) = 1.28 rounded to 3 digit precision
-BuildRequires: perl(POE) = 1.280
-BuildRequires: perl(POE::Component::Client::DNS) = 1.051
+BuildRequires: perl(IO::Socket::INET)
BuildRequires: perl(Net::IP) = 1.25
-
+BuildRequires: perl(POE) = 1.311
+BuildRequires: perl(POE::Component::Resolver) = 0.913
+BuildRequires: perl(POE::Component::Server::TCP)
+BuildRequires: perl(POE::Component::SSLify)
+BuildRequires: perl(POE::Wheel::ReadWrite)
+BuildRequires: perl(POE::Wheel::SocketFactory)
+BuildRequires: perl(Socket)
+BuildRequires: perl(Test::More)
+Requires: perl(Net::IP) = 1.25
+Requires: perl(POE) = 1.311
+Requires: perl(POE::Component::Resolver) = 0.913
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
# Satisfy automaticly generated requires that want this module = 0.0901
# (So the package has this provide in two versions, oh well.)
Provides: perl(POE::Component::Client::Keepalive) = %{version}
-### auto-added reqs!
-Requires: perl(Net::IP) = 1.25
-# Original perl(POE) = 1.28 rounded to 3 digit precision
-Requires: perl(POE) = 1.280
-Requires: perl(POE::Component::Client::DNS) = 1.051
-
%{?perl_default_filter}
%description
@@ -44,18 +44,20 @@ probably be silly.
%prep
%setup -q -n POE-Component-Client-Keepalive-%{real_ver}
chmod -c -x mylib/* t/*
+for test in t/release-pod-syntax.t \
+t/release-pod-coverage.t \
+t/000-report-versions.t; do
+sed -i 's/#!perl/#!\/usr\/bin\/perl/' ${test}
+done
%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 ';'
-
%{_fixperms} %{buildroot}/*
%check
@@ -65,16 +67,16 @@ find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null
';'
# this one test.
make test
-%clean
-rm -rf %{buildroot}
-
%files
-%defattr(-,root,root,-)
%doc CHANGES README mylib/ t/
%{perl_vendorlib}/*
%{_mandir}/man3/*.3*
%changelog
+* Thu Jan 19 2012 Petr Šabata con...@redhat.com - 0.2680-1
+- 0.268 bump
+- Spec cleanup
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.2620-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index 263ba03..83b3402 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3f15f0250ae7a74d6879d56011f515f9 POE-Component-Client-Keepalive-0.262.tar.gz
+318f18fce0837004fac8b792c5bbba1e POE-Component-Client-Keepalive-0.268.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 760472] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=760472 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.4-1. |perl-Directory-Queue-1.4-1. |el6 |el5 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2012-01-20 13:03:00 EST --- perl-Directory-Queue-1.4-1.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 760472] Upgrade to new upstream version
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=760472 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-Directory-Queue-1.4-1. |perl-Directory-Queue-1.4-1. |fc16|el6 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2012-01-20 13:02:23 EST --- perl-Directory-Queue-1.4-1.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report. -- 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. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: Ticket #262 - pid file not removed with systemd
https://fedorahosted.org/389/ticket/262 https://fedorahosted.org/389/attachment/ticket/262/0001-Ticket-262-pid-file-not-removed-with-systemd.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: fix mozldap build issues
From 95cd59308ca30b46ed3eb5cf34f9d1642390f2f9 Mon Sep 17 00:00:00 2001 From: Rich Megginson rmegg...@redhat.com Date: Fri, 20 Jan 2012 20:01:17 -0700 Subject: [PATCH] fix mozldap build issues ldap_start_tls_s needs ldap_ssl.h mozldap does not define LDAP_MAXINT --- .../servers/plugins/chainingdb/cb_conn_stateless.c |4 ldap/servers/slapd/slapi-plugin.h |5 + 2 files changed, 9 insertions(+), 0 deletions(-) diff --git a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c index ac10960..a9abc31 100644 --- a/ldap/servers/plugins/chainingdb/cb_conn_stateless.c +++ b/ldap/servers/plugins/chainingdb/cb_conn_stateless.c @@ -42,6 +42,10 @@ #include cb.h +#ifndef USE_OPENLDAP +#include ldap_ssl.h /* for start_tls */ +#endif + /* * Most of the complicated connection-related code lives in this file. Some * general notes about how we manage our connections to remote LDAP servers: diff --git a/ldap/servers/slapd/slapi-plugin.h b/ldap/servers/slapd/slapi-plugin.h index 2296351..e684fe0 100644 --- a/ldap/servers/slapd/slapi-plugin.h +++ b/ldap/servers/slapd/slapi-plugin.h @@ -342,6 +342,11 @@ NSPR_API(PRUint32) PR_fprintf(struct PRFileDesc* fd, const char *fmt, ...) #define LBER_OVERFLOW ((ber_tag_t) -3) /* 0xfffdU */ #endif +#ifndef LDAP_MAXINT +/* RFC 4511: maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- */ +#define LDAP_MAXINT (2147483647) +#endif + /* * Sequential access types */ -- 1.7.1 -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
