Re: Retired package by mistake - undo?
On Wed, 2010-12-15 at 07:43 -0800, Toshio Kuratomi wrote: On Tue, Dec 14, 2010 at 04:21:35PM +0200, Gilboa Davara wrote: On Tue, 2010-12-14 at 08:19 -0600, Jason L Tibbitts III wrote: OK, I found spring-installer and unretired it as well. You should log into pkgdb and claim both packages as they're currently orphaned. - J Thanks! And for reference, the best way to get admin help in the future is by opening a SCMAdmin request: https://fedoraproject.org/wiki/Package_SCM_admin_requests -Toshio Thanks. - Gilboa -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Documenting Fedora's package source control setup
On 2010-12-15, Jesse Keating jkeat...@redhat.com wrote: I thought I had done this, turns out I didn't. Go me! https://fedoraproject.org/wiki/Package_Source_Control I'd like to see codificated lookaside cache interface (host names, URL's authentication mechanism) and format of `sources' file. In other words specification that defines interface between the infrastrucure and tools like fedpkg. Something that allows to validate procedure like I gave in https://bugzilla.redhat.com/show_bug.cgi?id=619979#c16. Paper you provided is great however it's just an overview. Not a specification. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another request for comment, dist-git branch proposal
Jesse Keating venit, vidit, dixit 15.12.2010 23:10: https://fedoraproject.org/wiki/Dist_Git_Branch_Proposal I think I'm ready to present this to FESCo for consideration, but I'd like another round of eyes and thoughts/questions. Thanks! Maybe along with a micro migration guide: git remote prune origin git fetch origin git config --get-regexp branch.*.merge | sed -e 's#heads/\(.*\)/master#heads/\1#' | xargs -L1 git config fedpkg could learn to do this, of course. BTW: Is there any doc on what git commands a fedpkg command translates into? Cheers, Michael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why do package pushes to testing take so long?
Hi, I am waiting for almost 36 hours for packages to land in f13/testing and f14/testing. Any particular rationale behind this? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote: Jeez. Tha's just FUD. Of course we have discussed this openly with various folks. We haven't discussed this with you, Rich, personally, but well, I'll make a note now tht I'll DoS you now with every single choice we make, to get your blessing. What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Email-Reply] - 661697 rebuild for fixing problems with vendorach/lib
commit d9ac51563d290ee35ab01a3d1babe1d5bf63725c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 13:27:52 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Email-Reply.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Email-Reply.spec b/perl-Email-Reply.spec
index 67c9338..b253c0f 100644
--- a/perl-Email-Reply.spec
+++ b/perl-Email-Reply.spec
@@ -1,6 +1,6 @@
Name: perl-Email-Reply
Version:1.202
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Reply to an email message
Group: Development/Libraries
License:GPL+ or Artistic
@@ -45,6 +45,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*.3*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.202-8
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.202-7
- 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: noexec on /dev/shm
On Wed, Dec 15, 2010 at 07:17:21AM +0100, Lennart Poettering wrote: systemd documentation is actually pretty good and mostly comprehensive. Humble as I am I would even say that it is vastly superior to the majority of all open source projects. If you want to criticise us on something, pick something else, please. I think we could pretty justifiably criticise you on not being humble at all. :) But you're absolutely right about the documentation, which is indeed excellent. There's man pages for everything, and they're both comprehensive and sysadmin-friendly. -- Matthew Miller mat...@mattdm.org Senior Systems Architect -- Instructional Research Computing Services Harvard School of Engineering Applied Sciences -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Expect-Simple] - 661697 rebuild for fixing problems with vendorach/lib
commit a16d792a753fcc78945638286e394b39c826fe4a
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 14:57:37 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Expect-Simple.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Expect-Simple.spec b/perl-Expect-Simple.spec
index 3975d2d..14b5abf 100644
--- a/perl-Expect-Simple.spec
+++ b/perl-Expect-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-Expect-Simple
Version:0.04
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Wrapper around the Expect module
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-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
[perl-Exporter-Lite] - 661697 rebuild for fixing problems with vendorach/lib
commit 0dafbeebe95b4f0ace99a9b4c9c9d07b3e154650
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 15:03:18 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Exporter-Lite.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Exporter-Lite.spec b/perl-Exporter-Lite.spec
index ef0c7d6..951de21 100644
--- a/perl-Exporter-Lite.spec
+++ b/perl-Exporter-Lite.spec
@@ -1,6 +1,6 @@
Name: perl-Exporter-Lite
Version:0.02
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Lightweight exporting of variables
Group: Development/Libraries
License:GPL+ or Artistic
@@ -42,6 +42,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.02-9
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.02-8
- 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: Orphaning system-auto-death
On Wed, 2010-12-15 at 22:34 -0500, Matthew Miller wrote: On Wed, Dec 15, 2010 at 08:59:19PM -0500, Matthew Miller wrote: I think I'll change the f15 deadline to very-far-in-the-future, and then when I invent some spare time, work on some of the other ideas for automatic determination of the time. That's better than not having the package completely zapped. I have released ownership https://admin.fedoraproject.org/pkgdb/acls/name/system-autodeath go claim it and enjoy :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do package pushes to testing take so long?
Ralf Corsepius wrote: Hi, I am waiting for almost 36 hours for packages to land in f13/testing and f14/testing. Any particular rationale behind this? I think it has something to do with the announcement sent a little earlier: Outage: Fedora related services down 2010-12-15 22:00 UTC -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ExtUtils-InferConfig] - 661697 rebuild for fixing problems with vendorach/lib
commit 6b2b5aba02a325edcbe460041e760823ccfab88a
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 15:30:13 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-ExtUtils-InferConfig.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-ExtUtils-InferConfig.spec b/perl-ExtUtils-InferConfig.spec
index 60fdc37..5ed538a 100644
--- a/perl-ExtUtils-InferConfig.spec
+++ b/perl-ExtUtils-InferConfig.spec
@@ -1,6 +1,6 @@
Name: perl-ExtUtils-InferConfig
Version:1.04
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Infer Perl Configuration for non-running interpreters
License:GPL+ or Artistic
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.04-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Mon Jul 26 2010 Marcela Mašláňová mmasl...@redhat.com - 1.04-1
- latest update contains fix of test suite
--
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
Adding packages to buildroot directly from updates-testing
Hi, I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work. Currently we have to wait until package gets to stable for it to appear in buildroot. IMO this goes against the whole testing part of updates-testing. I'd like for packages to appear in buildroot as soon as they are in updates-testing. Reasoning: * Building deps is part of testing. If anything fails - package should be withdrawn from testing and not pushed. There are a few corner-cases I could think of where this approach could cause a bit of headaches, but in those cases even current process wouldn't help us much IMO. Any opinions on this? -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-ExtUtils-InstallPAR] - 661697 rebuild for fixing problems with vendorach/lib
commit 5f6f179ef23a88d8d80abe1376d97d1dfe616662
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 15:36:09 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-ExtUtils-InstallPAR.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-ExtUtils-InstallPAR.spec b/perl-ExtUtils-InstallPAR.spec
index 5e2e344..0084e2d 100644
--- a/perl-ExtUtils-InstallPAR.spec
+++ b/perl-ExtUtils-InstallPAR.spec
@@ -1,6 +1,6 @@
Name: perl-ExtUtils-InstallPAR
Version:0.03
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Install .par's into any installed perl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-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: Adding packages to buildroot directly from updates-testing
Stanislav Ochotnicky wrote: I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work. Currently we have to wait until package gets to stable for it to appear in buildroot. IMO this goes against the whole testing part of updates-testing. I'd like for packages to appear in buildroot as soon as they are in updates-testing. Reasoning: * Building deps is part of testing. If anything fails - package should be withdrawn from testing and not pushed. There are a few corner-cases I could think of where this approach could cause a bit of headaches, but in those cases even current process wouldn't help us much IMO. Any opinions on this? While I see some value in this, poisoning the buildroot is a grave danger here. I'd be hesitant to endorse it. Is this proposal based on any real examples of updates-testing pkgs breaking builds? Perhaps we could study these cases closer first. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 09:26 -0600, Rex Dieter wrote: Any opinions on this? While I see some value in this, poisoning the buildroot is a grave danger here. I'd be hesitant to endorse it. Is this proposal based on any real examples of updates-testing pkgs breaking builds? Perhaps we could study these cases closer first. I believe the Rawhide system of using a tag to test a set of dependent builds can also be used for stable release updates, no? If not, that seems a better solution than putting things straight into buildroot. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning all of my packages :(
Other people -- you know who you are, and thank you! :) -- have already been doing updates to my various (mostly java-related) packages in Fedora. However, just to make it formal: due to a combination of work and personal circumstances, I've had very few cycles for keeping up with Fedora since last spring or, and I don't see that changing any time in the near future. So, I'd like to open up any packages associated with my userid (mef) in the PackageDB for anyone who can give them more love. Is there an easier way to accomplish this in the package DB than clicking Relinquish Ownership on each package release individually? I hope to have more time for Fedora stuff again sometime later in the new year ... MEF -- Mary Ellen Foster -- http://www.macs.hw.ac.uk/~mef3/ Interaction Lab -- http://www.macs.hw.ac.uk/InteractionLab School of Mathematical and Computer Sciences, Heriot-Watt University Heriot-Watt University is a Scottish charity registered under charity number SC000278 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On 12/16/2010 04:42 PM, Adam Williamson wrote: On Thu, 2010-12-16 at 09:26 -0600, Rex Dieter wrote: Any opinions on this? While I see some value in this, poisoning the buildroot is a grave danger here. I'd be hesitant to endorse it. Is this proposal based on any real examples of updates-testing pkgs breaking builds? Perhaps we could study these cases closer first. I believe the Rawhide system of using a tag to test a set of dependent builds can also be used for stable release updates, no? If not, that seems a better solution than putting things straight into buildroot. Yes of course releng ticket can be filed and package can be added to override. But why do it? I'd say as soon as package is filed for addition to stable Fedora it should be suitable for buildroot as well. If it isn't something is wrong and we need to fix it anyway. It's definitely better if we screw up buildroot than if we screw up user's system. Only thing we accomplish by delaying adding to buildroot is delay when we notice problems. Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. -- Stanislav Ochotnicky sochotni...@redhat.com Associate Software Engineer - Base Operating Systems Brno PGP: 71A1677C Red Hat Inc. http://cz.redhat.com signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
Once upon a time, Stanislav Ochotnicky sochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? -- 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
[perl-File-DesktopEntry] - 661697 rebuild for fixing problems with vendorach/lib
commit 3258601f68b76d3931291e153c55b12dc76e5490
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 17:07:07 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-DesktopEntry.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-DesktopEntry.spec b/perl-File-DesktopEntry.spec
index a59fe58..b111877 100644
--- a/perl-File-DesktopEntry.spec
+++ b/perl-File-DesktopEntry.spec
@@ -1,6 +1,6 @@
Name: perl-File-DesktopEntry
Version:0.04
-Release:11%{?dist}
+Release:12%{?dist}
Summary:Object to handle .desktop files
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-12
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-11
- 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: Why do package pushes to testing take so long?
On 12/16/2010 03:18 PM, Rex Dieter wrote: Ralf Corsepius wrote: Hi, I am waiting for almost 36 hours for packages to land in f13/testing and f14/testing. Any particular rationale behind this? I think it has something to do with the announcement sent a little earlier: Outage: Fedora related services down 2010-12-15 22:00 UTC May-be, I don't know. All I can say, I submitted the packages ca. 2010-12-15 02:00 UTC and am waiting since. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: On Wed, Dec 15, 2010 at 07:21:25AM +0100, Lennart Poettering wrote: Jeez. Tha's just FUD. Of course we have discussed this openly with various folks. We haven't discussed this with you, Rich, personally, but well, I'll make a note now tht I'll DoS you now with every single choice we make, to get your blessing. What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change. Is. Going. To. Happen. This is technology. Good technical professionals learn new things quickly. So to all those thousands of Unix system administrators I suggest making a purchase here: http://www.saferacer.com/auto-racing-helmets/?cat=52 --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On 12/16/2010 03:35 PM, Stanislav Ochotnicky wrote: Hi, I'd like to propose a small(ish) change to how updates to Fx and Fx-1 work. Currently we have to wait until package gets to stable for it to appear in buildroot. IMO this goes against the whole testing part of updates-testing. I'd like for packages to appear in buildroot as soon as they are in updates-testing. Reasoning: * Building deps is part of testing. If anything fails - package should be withdrawn from testing and not pushed. There are a few corner-cases I could think of where this approach could cause a bit of headaches, but in those cases even current process wouldn't help us much IMO. Any opinions on this? +1, I had proposed somethings similar long time ago, but it was shot down, then. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do package pushes to testing take so long?
On Thu, 16 Dec 2010 17:14:23 +0100 Ralf Corsepius rc040...@freenet.de wrote: On 12/16/2010 03:18 PM, Rex Dieter wrote: Ralf Corsepius wrote: Hi, I am waiting for almost 36 hours for packages to land in f13/testing and f14/testing. Any particular rationale behind this? I think it has something to do with the announcement sent a little earlier: Outage: Fedora related services down 2010-12-15 22:00 UTC May-be, I don't know. All I can say, I submitted the packages ca. 2010-12-15 02:00 UTC and am waiting since. Yes, this is why. I was unable to start a push yesterday before these issues started and the outage is ongoing. I can't push until things are back to normal. Sorry for the delay... kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnicky sochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. I don't think this is worth even looking at until we have an AutoQA broken dep test live. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On 12/16/2010 05:28 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adamscmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnickysochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. How would this scenario be different from what we have now? Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why do package pushes to testing take so long?
On 12/16/2010 05:25 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 17:14:23 +0100 Ralf Corsepiusrc040...@freenet.de wrote: On 12/16/2010 03:18 PM, Rex Dieter wrote: Ralf Corsepius wrote: Hi, I am waiting for almost 36 hours for packages to land in f13/testing and f14/testing. Any particular rationale behind this? I think it has something to do with the announcement sent a little earlier: Outage: Fedora related services down 2010-12-15 22:00 UTC May-be, I don't know. All I can say, I submitted the packages ca. 2010-12-15 02:00 UTC and am waiting since. Yes, this is why. I was unable to start a push yesterday before these issues started and the outage is ongoing. I can't push until things are back to normal. Sorry for the delay... Thanks for clarifying this. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 09:28 -0700, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adams cmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnicky sochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. I don't think this is worth even looking at until we have an AutoQA broken dep test live. There may even be cases in which B won't have a broken dep and still won't work with the previous version of A (or at all). All packages that were built against the new A may have to be tracked down and rebuilt, like with GCC bug 634757, which becomes a PITA. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-FileHandle-Fmode] - 661697 rebuild for fixing problems with vendorach/lib
commit d650983a15b9a99fbca8a83d828464f3344d72e3
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 17:57:33 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-FileHandle-Fmode.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-FileHandle-Fmode.spec b/perl-FileHandle-Fmode.spec
index 4de31cb..fded805 100644
--- a/perl-FileHandle-Fmode.spec
+++ b/perl-FileHandle-Fmode.spec
@@ -1,6 +1,6 @@
Name: perl-FileHandle-Fmode
Version:0.09
-Release:8%{?dist}
+Release:9%{?dist}
Summary:FileHandle::Fmode Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -48,6 +48,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-9
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-8
- 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: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote: On 12/16/2010 05:28 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adamscmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnickysochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. How would this scenario be different from what we have now? As it works now, if the problem is found before A goes to stable (and we hope the testing process would find it), the build (or all of the builds in the custom tag) can just be untagged. The fallout is nicely contained. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-FileHandle-Unget] - 661697 rebuild for fixing problems with vendorach/lib
commit b674c180592f3f4570afd81ba87827109ea6ff37
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 18:02:59 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-FileHandle-Unget.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-FileHandle-Unget.spec b/perl-FileHandle-Unget.spec
index 2af8948..2d092c0 100644
--- a/perl-FileHandle-Unget.spec
+++ b/perl-FileHandle-Unget.spec
@@ -1,7 +1,7 @@
Summary: A FileHandle that supports ungetting of multiple bytes
Name: perl-FileHandle-Unget
Version: 0.1623
-Release: 4%{?dist}
+Release: 5%{?dist}
License: GPL+
Group: Development/Libraries
Url: http://search.cpan.org/dist/FileHandle-Unget/
@@ -50,6 +50,9 @@ string of bytes back on the input.
%{_mandir}/man3/FileHandle::Unget.3pm*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.1623-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.1623-4
- 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
[perl-File-HomeDir] - 661697 rebuild for fixing problems with vendorach/lib
commit 7bf485a59dd70dec852802da6348485ed2dad718
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 18:08:40 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-HomeDir.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-HomeDir.spec b/perl-File-HomeDir.spec
index 22b589a..75811ed 100644
--- a/perl-File-HomeDir.spec
+++ b/perl-File-HomeDir.spec
@@ -1,6 +1,6 @@
Name: perl-File-HomeDir
Version:0.93
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Find your home and other directories on any platform
Group: Development/Libraries
@@ -71,6 +71,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.93-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Wed Sep 22 2010 Petr Pisar ppi...@redhat.com - 0.93-1
- 0.93 bump
- Consolidate dependencies
--
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: A GUI tool for Fedora Packagers
Hi, On Tue, Dec 14, 2010 at 7:51 PM, Mat Booth fed...@matbooth.co.uk wrote: I have been using eclipse-fedorapackager for a while now and it works quite well, thanks for the effort that has gone into it. +1 My life revolves around Eclipse at my day job so using this plug-in wasn't a leap, but I've found that many people who aren't developers find Eclipse quite an overly large and intimidating product so maybe a little RCP app would be quite neat for people who don't need a full blown IDE. :-) That is what I am also thinking. As it was said earlier, that a stand alone version for Fedora Eclipse Packager can be made, we should start working on that. The code already exists for the backend. We can design a GUI with gtk+ and put all the features in a simple to use interface. Thanks, Regards, rtnpro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On 12/16/2010 06:00 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote: On 12/16/2010 05:28 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adamscmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnickysochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. How would this scenario be different from what we have now? As it works now, if the problem is found before A goes to stable (and we hope the testing process would find it), the build (or all of the builds in the custom tag) can just be untagged. The fallout is nicely contained. Hmm, are we talking about rawhide or release? As far as I understand, we are talking about releases ther updates-testing, where package A would land in testing in both cases. The detail which is not clear to me: What does the current buildroot contain? Does it comprise the packages in updates-testing? If yes, then there would be no technical difference to what we have now. If no, then we currently are at risk of building packages depending on A against the supposed to replaced versions in release/updates, i.e. we are at risk of producing silently broken packages. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On 12/16/2010 03:18 PM, seth vidal wrote: On Wed, 2010-12-15 at 22:34 -0500, Matthew Miller wrote: On Wed, Dec 15, 2010 at 08:59:19PM -0500, Matthew Miller wrote: I think I'll change the f15 deadline to very-far-in-the-future, and then when I invent some spare time, work on some of the other ideas for automatic determination of the time. That's better than not having the package completely zapped. I have released ownership https://admin.fedoraproject.org/pkgdb/acls/name/system-autodeath go claim it and enjoy :) Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all of my packages :(
On Thu, Dec 16, 2010 at 03:52:22PM +, Mary Ellen Foster wrote: Other people -- you know who you are, and thank you! :) -- have already been doing updates to my various (mostly java-related) packages in Fedora. However, just to make it formal: due to a combination of work and personal circumstances, I've had very few cycles for keeping up with Fedora since last spring or, and I don't see that changing any time in the near future. So, I'd like to open up any packages associated with my userid (mef) in the PackageDB for anyone who can give them more love. Is there an easier way to accomplish this in the package DB than clicking Relinquish Ownership on each package release individually? I hope to have more time for Fedora stuff again sometime later in the new year ... If you have a lot you can open a ticket in the infrastructure trac, https://fedorahosted.org/fedora-infrastructure/ and I or one ofthe cvsadmins can perform the orphaning for you. I've seen this post by you so I'll go ahead and do that now. -Toshio pgplVGlFrETsi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-MimeInfo] - 661697 rebuild for fixing problems with vendorach/lib
commit 65b2ea071c448a8f2673ebd24933efff89e6392f
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 18:14:09 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-MimeInfo.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-MimeInfo.spec b/perl-File-MimeInfo.spec
index d1e0eee..8e48fbc 100644
--- a/perl-File-MimeInfo.spec
+++ b/perl-File-MimeInfo.spec
@@ -1,6 +1,6 @@
Name: perl-File-MimeInfo
Version:0.15
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Determine file type and open application
License:GPL+ or Artistic
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.15-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.15-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
[perl-File-MMagic-XS] - 661697 rebuild for fixing problems with vendorach/lib
commit 690e2b93abd8ebbea8ff598e83db6cfc384645bf
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 18:24:34 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-MMagic-XS.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-MMagic-XS.spec b/perl-File-MMagic-XS.spec
index aebffb2..5f30069 100644
--- a/perl-File-MMagic-XS.spec
+++ b/perl-File-MMagic-XS.spec
@@ -1,6 +1,6 @@
Name: perl-File-MMagic-XS
Version:0.09006
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Guess file type with XS
Group: Development/Libraries
License:ASL 2.0 and (GPL+ or Artistic)
@@ -54,6 +54,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.09006-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Mon Jul 12 2010 Tom spot Callaway tcall...@redhat.com - 0.09006-1
- update to 0.09006
--
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: Orphaning system-auto-death
On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: On 12/16/2010 03:18 PM, seth vidal wrote: On Wed, 2010-12-15 at 22:34 -0500, Matthew Miller wrote: On Wed, Dec 15, 2010 at 08:59:19PM -0500, Matthew Miller wrote: I think I'll change the f15 deadline to very-far-in-the-future, and then when I invent some spare time, work on some of the other ideas for automatic determination of the time. That's better than not having the package completely zapped. I have released ownership https://admin.fedoraproject.org/pkgdb/acls/name/system-autodeath go claim it and enjoy :) Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all of my packages :(
Hi! Just in case someone is looking for the list of her packages: https://admin.fedoraproject.org/pkgdb/users/packages/mef I don't have time to do any of these. However, I would love to see someone taking over gernonimo*, ice, jarjar, javamail, maven*, pl... - at least Mary. Take your time! -of On 12/16/2010 04:52 PM, Mary Ellen Foster wrote: Other people -- you know who you are, and thank you! :) -- have already been doing updates to my various (mostly java-related) packages in Fedora. However, just to make it formal: due to a combination of work and personal circumstances, I've had very few cycles for keeping up with Fedora since last spring or, and I don't see that changing any time in the near future. So, I'd like to open up any packages associated with my userid (mef) in the PackageDB for anyone who can give them more love. Is there an easier way to accomplish this in the package DB than clicking Relinquish Ownership on each package release individually? I hope to have more time for Fedora stuff again sometime later in the new year ... MEF -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On 12/16/2010 06:26 PM, seth vidal wrote: On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: On 12/16/2010 03:18 PM, seth vidal wrote: On Wed, 2010-12-15 at 22:34 -0500, Matthew Miller wrote: On Wed, Dec 15, 2010 at 08:59:19PM -0500, Matthew Miller wrote: I think I'll change the f15 deadline to very-far-in-the-future, and then when I invent some spare time, work on some of the other ideas for automatic determination of the time. That's better than not having the package completely zapped. I have released ownership https://admin.fedoraproject.org/pkgdb/acls/name/system-autodeath go claim it and enjoy :) Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. Not necessarily - Yum could simply issue a warning and continue to work, yum could have a --disable-expiration-warnings option, ... There are many possibilities -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On Thu, 2010-12-16 at 18:33 +0100, Ralf Corsepius wrote: On 12/16/2010 06:26 PM, seth vidal wrote: On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. Not necessarily - Yum could simply issue a warning and continue to work, yum could have a --disable-expiration-warnings option, ... There are many possibilities Rather than push the issue onto the user, I think the right solution would be for the fedora repo definition to have an option updated_by=updates that causes yum not to check its expiration when the updates repo is also enabled. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On 12/16/2010 06:43 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 18:33 +0100, Ralf Corsepius wrote: On 12/16/2010 06:26 PM, seth vidal wrote: On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. Not necessarily - Yum could simply issue a warning and continue to work, yum could have a --disable-expiration-warnings option, ... There are many possibilities Rather than push the issue onto the user, I don't think this is pushing the issue onto the user. I'd consider this to be warning them about you might be doing something unwise. I think the right solution would be for the fedora repo definition to have an option updated_by=updates that causes yum not to check its expiration when the updates repo is also enabled. Yes, this would also be an alternative, except that one also would have to take users into account who run plain DVD Fedora w/o updates and use-cases which run entirely off-line. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all of my packages :(
I'm CC'ing comaintainers of the affected packages. On Thu, Dec 16, 2010 at 03:52:22PM +, Mary Ellen Foster wrote: Other people -- you know who you are, and thank you! :) -- have already been doing updates to my various (mostly java-related) packages in Fedora. However, just to make it formal: due to a combination of work and personal circumstances, I've had very few cycles for keeping up with Fedora since last spring or, and I don't see that changing any time in the near future. So, I'd like to open up any packages associated with my userid (mef) in the PackageDB for anyone who can give them more love. Is there an easier way to accomplish this in the package DB than clicking Relinquish Ownership on each package release individually? I hope to have more time for Fedora stuff again sometime later in the new year ... The following packages have been orphaned in Fedora 13, 14, and devel: BibTool -- A Tool for manipulating BibTeX data bases aduna-commons-concurrent -- Extensions to the Java Concurrency package aduna-commons-i18n -- Internationalization and localization utilities aduna-commons-pom -- Aduna commons parent POM aduna-commons-text -- Manipulate/transform/parse text in various ways aduna-root-poms -- Root POMs for Aduna projects apache-resource-bundles -- Apache JAR resource bundle cglib -- Code generation library for Java eclipse-slice2java -- A plugin that integrates Eclipse with Ice object middleware geronimo-jms -- J2EE JMS v1.1 API geronimo-jta -- J2EE JTA v1.1 API geronimo-parent-poms -- Parent POM files for geronimo-specs ice -- The Ice base runtime and services janino -- An embedded Java compiler jarjar -- Jar Jar Links javamail -- Java Mail API jgoodies-forms -- Framework to lay out and implement elegant Swing panels in Java jgoodies-looks -- Free high-fidelity Windows and multi-platform appearance kaffeine -- Xine-based media player latexmk -- A make-like utility for LaTeX files libgle -- A tubing and extrusion library for OpenGL logback -- A Java logging library maven-doxia -- Content generation framework maven-doxia-tools -- Maven Doxia integration tools maven-javadoc-plugin -- Maven Javadoc plugin mcpp -- Alternative C/C++ preprocessor pdfbook -- Rearrange pages in a PDF file into signatures pl -- SWI-Prolog - Edinburgh compatible Prolog compiler swingx -- A collection of Swing components tetex-elsevier -- Elsevier LaTeX style files and documentation tetex-tex4ht -- Translates TeX and LaTeX into HTML or XML+MathML trove4j -- High performance collections for Java You can pick them up if you like. -Toshio pgpZP9w1IlWKs.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-Pid] - 661697 rebuild for fixing problems with vendorach/lib
commit 05e8108ba1cbbff60180bc810715bbc10df244de
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 18:57:09 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-Pid.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-Pid.spec b/perl-File-Pid.spec
index bf5b491..6c9559a 100644
--- a/perl-File-Pid.spec
+++ b/perl-File-Pid.spec
@@ -1,6 +1,6 @@
Name: perl-File-Pid
Version:1.01
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Pid File Manipulation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.01-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.01-4
- 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: Orphaning system-auto-death
On Thu, 2010-12-16 at 18:54 +0100, Ralf Corsepius wrote: On 12/16/2010 06:43 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 18:33 +0100, Ralf Corsepius wrote: On 12/16/2010 06:26 PM, seth vidal wrote: On Thu, 2010-12-16 at 18:13 +0100, Ralf Corsepius wrote: Just a thought: How about equipping a repo's metadata with some sort of expiration/best before date, which yum etc. could use to warn users? If we had something like this, system-auto-death etc. would become superfluous. it would mean we'd have to be able/willing to push new metadata out to the base repo so that the repo could be used at all for future installs. Not necessarily - Yum could simply issue a warning and continue to work, yum could have a --disable-expiration-warnings option, ... There are many possibilities Rather than push the issue onto the user, I don't think this is pushing the issue onto the user. I'd consider this to be warning them about you might be doing something unwise. I think the right solution would be for the fedora repo definition to have an option updated_by=updates that causes yum not to check its expiration when the updates repo is also enabled. Yes, this would also be an alternative, except that one also would have to take users into account who run plain DVD Fedora w/o updates and use-cases which run entirely off-line. I was referring to the issue Seth raised where using the fedora repo would produce an expiration warning that is bogus (i.e., the user is not at risk) provided that the updates repo is also enabled. That can and should be solved on our end. Showing the warning to users who don't use the updates repo is correct behavior, though we could separately have an option for the user to hide the warning if they already know about it and find it annoying. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-Read] - 661697 rebuild for fixing problems with vendorach/lib
commit 1d1eb61c1392c82f9c71f55dd1905bc2b8fe727e
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 19:08:22 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-Read.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-Read.spec b/perl-File-Read.spec
index a753341..21c1a18 100644
--- a/perl-File-Read.spec
+++ b/perl-File-Read.spec
@@ -1,6 +1,6 @@
Name: perl-File-Read
Version:0.0801
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Unique interface for reading one or more files
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.0801-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.0801-3
- 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
[perl-File-ReadBackwards] - 661697 rebuild for fixing problems with vendorach/lib
commit 90ea1ca259ff68fb8b39fc080c2085d322549810
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 19:13:40 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-ReadBackwards.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-ReadBackwards.spec b/perl-File-ReadBackwards.spec
index 76ceb18..9dc00c8 100644
--- a/perl-File-ReadBackwards.spec
+++ b/perl-File-ReadBackwards.spec
@@ -1,6 +1,6 @@
Name: perl-File-ReadBackwards
Version:1.04
-Release:9%{?dist}
+Release:10%{?dist}
Summary:File::ReadBackwards Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.04-10
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.04-9
- 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: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 18:11 +0100, Ralf Corsepius wrote: On 12/16/2010 06:00 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 17:49 +0100, Ralf Corsepius wrote: On 12/16/2010 05:28 PM, Kevin Fenzi wrote: On Thu, 16 Dec 2010 10:03:30 -0600 Chris Adamscmad...@hiwaay.net wrote: Once upon a time, Stanislav Ochotnickysochotni...@redhat.com said: Note that I am not saying things should go into buildroot as soon as they are built, but as soon as they are in updates-testing. There is a difference. There will still be reasons to use tags/overrides. That makes the push process much more fragile/difficult. If you use a updates-testing build of package A, and package B (that depends on package A) gets rebuilt, then you may have a package B that can't be pushed to stable until package A gets pushed. What if there's a security update on package B that needs to go to stable ASAP? Additionally, what if package A is built, after a few days serious problems are found in it and it's deleted until the maintainer can sort them out. What happens to packages B, C, D, and E that built against this version? They will have broken deps. How would this scenario be different from what we have now? As it works now, if the problem is found before A goes to stable (and we hope the testing process would find it), the build (or all of the builds in the custom tag) can just be untagged. The fallout is nicely contained. Hmm, are we talking about rawhide or release? As far as I understand, we are talking about releases ther updates-testing, where package A would land in testing in both cases. The detail which is not clear to me: What does the current buildroot contain? Does it comprise the packages in updates-testing? dist-f14-build, which consists of updates + buildroot overrides + the same inherited from previous distribution versions. You can see the details here: http://koji.fedoraproject.org/koji/search?terms=dist-f14-buildtype=tagmatch=exact (BTW, it seems that a custom tag would generally be better than a buildroot override for the reasons we are discussing even if there's only one dependent package, unless that would put some kind of strain on the infrastructure. Is a request for a custom tag more work than a buildroot override request for the releng team?) If no, then we currently are at risk of building packages depending on A against the supposed to replaced versions in release/updates, i.e. we are at risk of producing silently broken packages. But this is no different from the case of a package C built against the old A before the new A came into existence. In most cases in which a new A makes it to stable, it will be backward-compatible with packages built against the old A. If it is not, all dependent packages need to be rebuilt at some point. But if B happens to be rebuilt for some other reason while the new A is in testing, performing that build against the old A is no different from declining to rebuild C against the new A at that time. -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Guidelines Change] Changes to the Packaging Guidelines
On Thursday 16 December 2010, Jon Masters wrote: On Wed, 2010-12-15 at 23:57 +0200, Ville Skyttä wrote: But how many packages nowadays require a man page reader simply because they install man pages? Well, since it's a guideline, it's worth discussion. Sure there's only 18 in your list, but that sounds more like a bug than a feature. Similarly, for docs in HTML format we could probably do with some kind of dependency suggestion (I'm not sure what the Fedora version of RPM recommended way of doing dependency level suggestions is now). I would think that would be the ideal, to recommend these things but not require them to be installed if it's just documentation files. I think the policy should be to somehow recommend the additional bits, then you can add but not require in place of the existing wording. I disagree, in my opinion even a recommendation in this context would be too much. I think the line when to use recommendations should be drawn to something that adds features or makes software work better/more efficiently. Anyway, what is the current Fedora RPM way of doing suggestions? I've seen this stuff in SuSE, and other package managers (including RPM). There is no support for that in Fedora's rpm. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500: On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change.\nIs.\nGoing.\nTo.\nHappen. That's a too black-and-white view. Of course there is and will be change - what would we all be doing here if there were nothing to change, after all? The thing that needs to be appreciate is that every change has _costs_ on the user-base. I can't quickly find out good numbers on the number of server users of Fedora and Fedora-derived distributions; based on http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18728forum=14 , let's stipulate that there are 1,000,000 installations (which is almost certainly a huge understatement), with 10 servers per administrator on average, so 100,000 Linux system administrators. Better numbers would be welcome. * You simplify existing code, which changes a rarely-used configuration value that shouldn't affect anything in most cases, nevertheless requires a release note. Say 10% of the system administrators reads the release notes, and reading the release note takes 10 seconds. The code simplification just cost our userbase more than 3 working days, with nothing to show for it. Did the code simplification save the programmers 3 days, so that at least overall there was a net benefit? * You replace a configuration file, or change its syntax, so that old knowledge and old kickstart scripts no longer apply. Say, again, that this change affects 10% of the system administrators, and that the change is fairly trivial, so reading the documentation and updating existing configuration scripts takes only 1 hour, and validating the change and the associated administrative overhead (keeping track of the change) takes 3 hours. Now the configuration file change has cost our userbase about 19 working _years_. To be worth it across the population of system administrators, the change needs to save the average system administrator 24 minutes before the configuration method changes again, or provide some other equivalent benefit. Saving the average system administrator 24 minutes is not easy (try thinking of a configuration change that would do that), and the more frequent changes of the configuration are, the more pronounced the benefits of the feature need to be. * You replace a whole subsystem, requiring _each_ system administrator to study the new subsystem for 10 hours, and to update the existing configuration, validate it and so on, which takes 30 hours. The change has cost our userbase a working week; to be worth it, it also needs to save each system administrator a working week. Again, the more frequent the subsystem changes are, the more pronounced the benefits of the changes need to be. So, yes, change is going to happen, and some change is clearly good. But when there are 10 programmers on a project and 100,000 users, each change has to be _very obviously_ good, or it might be better avoided. Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-Which] - 661697 rebuild for fixing problems with vendorach/lib
commit 562cfcf65e0ff925a8c85655178b17f70d374442
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 20:23:56 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-File-Which.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-File-Which.spec b/perl-File-Which.spec
index be18027..9c29cb9 100644
--- a/perl-File-Which.spec
+++ b/perl-File-Which.spec
@@ -1,6 +1,6 @@
Name: perl-File-Which
Version:1.09
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Portable implementation of the 'which' utility
Group: Development/Libraries
@@ -56,6 +56,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.09-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.09-3
- 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: A GUI tool for Fedora Packagers
On 16 December 2010 17:09, Ratnadeep Debnath rtn...@gmail.com wrote: Hi, On Tue, Dec 14, 2010 at 7:51 PM, Mat Booth fed...@matbooth.co.uk wrote: I have been using eclipse-fedorapackager for a while now and it works quite well, thanks for the effort that has gone into it. +1 My life revolves around Eclipse at my day job so using this plug-in wasn't a leap, but I've found that many people who aren't developers find Eclipse quite an overly large and intimidating product so maybe a little RCP app would be quite neat for people who don't need a full blown IDE. :-) That is what I am also thinking. As it was said earlier, that a stand alone version for Fedora Eclipse Packager can be made, we should start working on that. The code already exists for the backend. We can design a GUI with gtk+ and put all the features in a simple to use interface. Well, the GUI already exists as an Eclipse IDE plug-in, my suggestion was to just turn that into an Eclipse Rich Client Platform application (read up on Eclipse RCP to see what I mean.) I believe that is also what Chris Aniszczyk hinted at. There's really no need to redesign it from scratch! -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, 2010-12-16 at 20:16 +0100, Miloslav Trmač wrote: Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500: On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change.\nIs.\nGoing.\nTo.\nHappen. That's a too black-and-white view. Of course there is and will be change - what would we all be doing here if there were nothing to change, after all? The thing that needs to be appreciate is that every change has _costs_ on the user-base. [...] So, yes, change is going to happen, and some change is clearly good. But when there are 10 programmers on a project and 100,000 users, each change has to be _very obviously_ good, or it might be better avoided. Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Looking at real costs and benefits is the right approach. But do not overlook potential benefits of making it practical to add features that will help the sysadmins or avoiding a security issue later that the sysadmins would otherwise have to scramble to fix (maybe not applicable to /dev/shm, but in general). -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Font-TTF] - 661697 rebuild for fixing problems with vendorach/lib
commit 8bdf172bcf48584008163300fabe9112d931b0fa
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 20:52:07 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Font-TTF.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Font-TTF.spec b/perl-Font-TTF.spec
index fe7036a..319f503 100644
--- a/perl-Font-TTF.spec
+++ b/perl-Font-TTF.spec
@@ -2,7 +2,7 @@
Name:perl-%{cpanname}
Version: 0.45
-Release: 7%{?dist}
+Release: 8%{?dist}
Summary: Perl library for modifying TTF font files
Group: Development/Libraries
@@ -83,6 +83,9 @@ rm -fr %{buildroot}
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.45-8
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 0.45-7
- 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
[perl-Font-TTFMetrics] - 661697 rebuild for fixing problems with vendorach/lib
commit e5b3a8b1b36655e7a0b27446762c360090f3e5cc
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 20:57:19 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Font-TTFMetrics.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Font-TTFMetrics.spec b/perl-Font-TTFMetrics.spec
index bf2dd78..4e1757d 100644
--- a/perl-Font-TTFMetrics.spec
+++ b/perl-Font-TTFMetrics.spec
@@ -1,6 +1,6 @@
Name: perl-Font-TTFMetrics
Version:0.1
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Parser for the TTF file
License:GPL+ or Artistic
Group: Development/Libraries
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.1-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Tue Aug 17 2010 Xavier Bachelot xav...@bachelot.org 0.1-2
- Add missing BR: perl(Test::More).
--
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: A GUI tool for Fedora Packagers
On 14/12/10 04:38, Ratnadeep Debnath wrote: Hi, I've been thinking for sometime now for a GUI for the Fedora Packagers. There are some steps during the packaging life cycle which needs to be repeated again and again. So, I was thinking of having some kind of one click system for updating the packages, like submitting for a koji scratch build, uploading the packages, updating bug request, etc. I want to create a desktop app for this. If some steps have already in this regard, I would like to contribute to it, else I will start working on this project. Thanks, Regards, rtnpro, http://ratnadeepdebnath.wordpress.com/ ---sent from Nokia C5--- If you do this, please can it show (or have an option to show) the commands it is running? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-forks] - 661697 rebuild for fixing problems with vendorach/lib
commit 106552bb891dbcada816cf6b89ecd633cb05438a
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 21:03:00 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-forks.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-forks.spec b/perl-forks.spec
index 6e384b8..1a98abe 100644
--- a/perl-forks.spec
+++ b/perl-forks.spec
@@ -1,6 +1,6 @@
Name: perl-forks
Version:0.34
-Release:1%{?dist}
+Release:2%{?dist}
Summary:A drop-in replacement for Perl threads using fork()
Group: Development/Libraries
@@ -76,6 +76,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.34-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Thu Jun 17 2010 Marcela Maslanova mmasl...@redhat.com - 0.34-1
- update because https://rt.cpan.org/Public/Bug/Display.html?id=56263
--
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-Font-AFM] - 661697 rebuild for fixing problems with vendorach/lib
commit cea45b4e501f623b4b43466739a23daa88d09128
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 20:45:48 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Font-AFM.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Font-AFM.spec b/perl-Font-AFM.spec
index 77f9998..920cc3a 100644
--- a/perl-Font-AFM.spec
+++ b/perl-Font-AFM.spec
@@ -1,6 +1,6 @@
Name: perl-Font-AFM
Version:1.20
-Release: 5%{?dist}
+Release: 6%{?dist}
Summary:Perl interface to Adobe Font Metrics files
Group: Development/Libraries
@@ -52,6 +52,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Font*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.20-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat May 01 2010 Marcela Maslanova mmasl...@redhat.com - 1.20-5
- 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
[perl-Format-Human-Bytes] - 661697 rebuild for fixing problems with vendorach/lib
commit a2435359e609130ae8fb2b2a8773eb14d3417198
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 21:11:19 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Format-Human-Bytes.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Format-Human-Bytes.spec b/perl-Format-Human-Bytes.spec
index 0eba61a..fade480 100644
--- a/perl-Format-Human-Bytes.spec
+++ b/perl-Format-Human-Bytes.spec
@@ -1,6 +1,6 @@
Name: perl-Format-Human-Bytes
Version:0.06
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Format a bytecount and make it human readable
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.06-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Wed Sep 15 2010 Petr Sabata psab...@redhat.com - 0.06-1
- New release, v0.06
- License changed to Perl (GPL+ or Artistic)
--
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: Adding packages to buildroot directly from updates-testing
On 12/16/10 10:29 AM, Matt McCutchen wrote: (BTW, it seems that a custom tag would generally be better than a buildroot override for the reasons we are discussing even if there's only one dependent package, unless that would put some kind of strain on the infrastructure. Is a request for a custom tag more work than a buildroot override request for the releng team?) A custom tag would slow things down considerably. When doing a buildroot override, the newRepo task can take the pre-existing repodata into account when calling createrepo and be done fairly quickly (a few minutes of actual createrepo time). A new custom tag would require creating fresh repodata from scratch which can take an hour or more of actual createrepo time. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-FreezeThaw] - 661697 rebuild for fixing problems with vendorach/lib
commit 03c59e913b6089f5475ece4de993ebd8053ac3bd
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 21:16:52 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-FreezeThaw.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-FreezeThaw.spec b/perl-FreezeThaw.spec
index 6679fb6..e66bf07 100644
--- a/perl-FreezeThaw.spec
+++ b/perl-FreezeThaw.spec
@@ -1,6 +1,6 @@
Name: perl-FreezeThaw
Version:0.5001
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Convert Perl structures to strings and back
Group: Development/Libraries
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.5001-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri May 14 2010 Ralf Corsépius corse...@fedoraproject.org - 0.5001-2
- Bump version for 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: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 12:14 -0800, Jesse Keating wrote: On 12/16/10 10:29 AM, Matt McCutchen wrote: (BTW, it seems that a custom tag would generally be better than a buildroot override for the reasons we are discussing even if there's only one dependent package, unless that would put some kind of strain on the infrastructure. Is a request for a custom tag more work than a buildroot override request for the releng team?) A custom tag would slow things down considerably. When doing a buildroot override, the newRepo task can take the pre-existing repodata into account when calling createrepo and be done fairly quickly (a few minutes of actual createrepo time). A new custom tag would require creating fresh repodata from scratch which can take an hour or more of actual createrepo time. I assume you're referring to createrepo --update? How hard would it be to seed the new tag with the repodata of one of the tags it inherits? An alternative approach would be to mirror the semantics of tag inheritance by having builds use multiple yum repositories, possibly with priorities, instead of explicitly computing the resulting repodata for every tag. Would that be feasible? -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: A GUI tool for Fedora Packagers
- Mat Booth fed...@matbooth.co.uk wrote: That is what I am also thinking. As it was said earlier, that a stand alone version for Fedora Eclipse Packager can be made, we should start working on that. The code already exists for the backend. We can design a GUI with gtk+ and put all the features in a simple to use interface. Well, the GUI already exists as an Eclipse IDE plug-in, my suggestion was to just turn that into an Eclipse Rich Client Platform application (read up on Eclipse RCP to see what I mean.) I believe that is also what Chris Aniszczyk hinted at. There's really no need to redesign it from scratch! Mat is right. IMO an RCP app would be the way to go if there's a desire for a stripped down interface. It would certainly avoid reinventing the wheel :) Let me know if you are interested in contributing to Eclipse Fedora Packager. Help would be very much appreciated. Cheers, Severin -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding packages to buildroot directly from updates-testing
On 12/16/10 12:22 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 12:14 -0800, Jesse Keating wrote: On 12/16/10 10:29 AM, Matt McCutchen wrote: (BTW, it seems that a custom tag would generally be better than a buildroot override for the reasons we are discussing even if there's only one dependent package, unless that would put some kind of strain on the infrastructure. Is a request for a custom tag more work than a buildroot override request for the releng team?) A custom tag would slow things down considerably. When doing a buildroot override, the newRepo task can take the pre-existing repodata into account when calling createrepo and be done fairly quickly (a few minutes of actual createrepo time). A new custom tag would require creating fresh repodata from scratch which can take an hour or more of actual createrepo time. I assume you're referring to createrepo --update? How hard would it be to seed the new tag with the repodata of one of the tags it inherits? Yes, I'm referring to --update (and --skip-stat). Seeding the new tag with one of the tags it inherits would take some code in koji. I don't know how much code it would take, but it would take code. An alternative approach would be to mirror the semantics of tag inheritance by having builds use multiple yum repositories, possibly with priorities, instead of explicitly computing the resulting repodata for every tag. Would that be feasible? Again it would take code, and quite a bit of logic to figure out what packages are blocked in various tags to make sure the repo config files used exclude the right packages, etc... -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning system-auto-death
On Thu, 2010-12-16 at 14:32 -0600, Matt Domsch wrote: On Wed, Dec 15, 2010 at 09:24:40AM -0500, seth vidal wrote: After this bug: https://bugzilla.redhat.com/show_bug.cgi?id=663340 I realize I'm not remembering to update the EOL date often enough. So, I'm orphaning system-auto-death. If no one steps up to take care of it I'm going to issue an update which disables the cron job. I mentioned this in the bug, but preupgrade needs to know about the EOL date of a release too. Hence: http://mirrors.fedoraproject.org/releases.txt includes an eol-date entry: [Fedora 12 (Constantine)] stable=True preupgrade-ok=True version=12 mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-12arch=$basearch installmirrorlist=http://mirrors.fedoraproject.org/mirrorlist?path=pub/fedora/linux/releases/12/Fedora/$basearch/os eol-date=20101202 This is kept updated (mostly by me), it lives in the fedora-web git tree in infrastructure. An excellent item for the fabulous new maintainer, Matt Miller, to take up! :) -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote: Casey Dahlin píše v Čt 16. 12. 2010 v 11:19 -0500: On Thu, Dec 16, 2010 at 12:27:34PM +, Richard W.M. Jones wrote: What you don't understand is that you are throwing away the experience and knowledge of thousands of Unix system administrators. Almost of all of them do not even read this mailing list. Rich. I hate this argument. The experience and knowledge claim applies to everything we could possibly change. Change.\nIs.\nGoing.\nTo.\nHappen. That's a too black-and-white view. Of course there is and will be change - what would we all be doing here if there were nothing to change, after all? The thing that needs to be appreciate is that every change has _costs_ on the user-base. I think the view I was presented with was too black-and-white. Richard began with essentially change is bad. I responded. You've really wholly replaced the argument I was reacting to. Which is a good thing. The conversation should have begun here. I can't quickly find out good numbers on the number of server users of Fedora and Fedora-derived distributions; based on http://www.centos.org/modules/newbb/viewtopic.php?topic_id=18728forum=14 , let's stipulate that there are 1,000,000 installations (which is almost certainly a huge understatement), with 10 servers per administrator on average, so 100,000 Linux system administrators. Better numbers would be welcome. http://fedoraproject.org/wiki/Statistics That's the best we have. Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Mirek Measurable != significant. Great programmers and architects have an instinct for something called defect avoidance. You can't measure it, since the unit would be number of bugs/bug-related outages and problems which never happened. Depending on your instincts on what that value might be, cleaner could be the single most important thing to improve in the entire distro. You can guess my own instincts on the subject. This sort of immeasurability is everywhere in computing. Its what causes most major corporate security breaches (well, we haven't had a security breach in awhile, I guess we don't need to spend so much on a security team.) Its what spawned the desperate rationalization all software has bugs, which is an excuse to not have to measure how well you avoid putting bugs in the code. For my part, I believe in trying to write software that can't break, even if I'm not always successful. Part of that effort is ripping off anything that's loose. If its purpose is questionable, or its exposed in a semantically iffy way, it needs to be ripped out. --CJD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: noexec on /dev/shm
Casey Dahlin píše v Čt 16. 12. 2010 v 15:50 -0500: On Thu, Dec 16, 2010 at 08:16:53PM +0100, Miloslav Trmač wrote: Especially minor changes that don't bring any measurable benefit (perhaps making the system cleaner or making programmer's life more convenient) but require time from each user to adapt are better abandoned than implemented. Mirek Measurable != significant. Great programmers and architects have an instinct for something called defect avoidance. You can't measure it, since the unit would be number of bugs/bug-related outages and problems which never happened. Depending on your instincts on what that value might be, cleaner could be the single most important thing to improve in the entire distro. The trouble is that we can't all agree on the immeasurable benefits (but we can probably agree on the existence of the measurable costs), which is why the monster threads about systemd arrive so regularly. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 663801] CVE-2010-3438 perl-POE-Component-IRC: arbitrary IRC command execution due to insufficient stripping of CR/LF
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=663801 Vincent Danen vda...@redhat.com changed: What|Removed |Added CC||cw...@alumni.drew.edu, ||fedora-perl-devel-l...@redh ||at.com -- 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: Adding packages to buildroot directly from updates-testing
On Thu, 2010-12-16 at 12:28 -0800, Jesse Keating wrote: On 12/16/10 12:22 PM, Matt McCutchen wrote: An alternative approach would be to mirror the semantics of tag inheritance by having builds use multiple yum repositories, possibly with priorities, instead of explicitly computing the resulting repodata for every tag. Would that be feasible? Again it would take code, and quite a bit of logic to figure out what packages are blocked in various tags to make sure the repo config files used exclude the right packages, etc... How about shipping the block list in the repository metadata and modifying yum-plugin-priorities to read it and insert the blocks into the priority dictionary just like packages? I think that would give the right semantics. (I'm not prepared to contribute now. I'm just having fun speculating and hoping that if we reach a solution that is easy enough to be worthwhile, someone will implement it. Is there a better list for this discussion?) -- Matt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Geo-Constants] - 661697 rebuild for fixing problems with vendorach/lib
commit 273383d1ff2ab1ccf206bd9f9c1c7a2632fefcae
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 22:22:03 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Geo-Constants.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Geo-Constants.spec b/perl-Geo-Constants.spec
index 854dbf1..1eb672a 100644
--- a/perl-Geo-Constants.spec
+++ b/perl-Geo-Constants.spec
@@ -1,6 +1,6 @@
Name: perl-Geo-Constants
Version:0.06
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Standard Geo:: constants
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.06-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun May 02 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
[Bug 663801] CVE-2010-3438 perl-POE-Component-IRC: arbitrary IRC command execution due to insufficient stripping of CR/LF
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=663801 Vincent Danen vda...@redhat.com changed: What|Removed |Added Depends on||663803 --- Comment #1 from Vincent Danen vda...@redhat.com 2010-12-16 16:19:19 EST --- Created perl-POE-Component-IRC tracking bugs for this issue Affects: fedora-all [bug 663803] -- 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
[Bug 663803] New: CVE-2010-3438 perl-POE-Component-IRC: arbitrary IRC command execution due to insufficient stripping of CR/LF [fedora-all]
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: CVE-2010-3438 perl-POE-Component-IRC: arbitrary IRC command execution due to insufficient stripping of CR/LF [fedora-all] https://bugzilla.redhat.com/show_bug.cgi?id=663803 Summary: CVE-2010-3438 perl-POE-Component-IRC: arbitrary IRC command execution due to insufficient stripping of CR/LF [fedora-all] Product: Fedora Version: 14 Platform: All OS/Version: Linux Status: NEW Keywords: Security, SecurityTracking Severity: medium Priority: medium Component: perl-POE-Component-IRC AssignedTo: cw...@alumni.drew.edu ReportedBy: vda...@redhat.com QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Blocks: 663801 Classification: Fedora Target Release: --- This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected Fedora versions. For comments that are specific to the vulnerability please use bugs filed against Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please include the bug IDs of the respective parent bugs filed against the Security Response product. Please mention CVE ids in the RPM changelog when available. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=663801 Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please only close it when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] -- 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: Adding packages to buildroot directly from updates-testing
On 12/16/10 1:20 PM, Matt McCutchen wrote: On Thu, 2010-12-16 at 12:28 -0800, Jesse Keating wrote: On 12/16/10 12:22 PM, Matt McCutchen wrote: An alternative approach would be to mirror the semantics of tag inheritance by having builds use multiple yum repositories, possibly with priorities, instead of explicitly computing the resulting repodata for every tag. Would that be feasible? Again it would take code, and quite a bit of logic to figure out what packages are blocked in various tags to make sure the repo config files used exclude the right packages, etc... How about shipping the block list in the repository metadata and modifying yum-plugin-priorities to read it and insert the blocks into the priority dictionary just like packages? I think that would give the right semantics. (I'm not prepared to contribute now. I'm just having fun speculating and hoping that if we reach a solution that is easy enough to be worthwhile, someone will implement it. Is there a better list for this discussion?) Any of these solutions is going to take code, and coordination with Koji upstream. Won't really know which path is best until they are tried. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Geo-Inverse] - 661697 rebuild for fixing problems with vendorach/lib
commit 9bd0a436d17a0dc096ee62035b1fb0b02479709b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 22:50:30 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Geo-Inverse.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Geo-Inverse.spec b/perl-Geo-Inverse.spec
index 37d1697..71b1b71 100644
--- a/perl-Geo-Inverse.spec
+++ b/perl-Geo-Inverse.spec
@@ -1,6 +1,6 @@
Name: perl-Geo-Inverse
Version:0.05
-Release:6%{?dist}
+Release:7%{?dist}
Summary:Calculate geographic distance from a lat lon pair
Group: Development/Libraries
@@ -53,6 +53,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-7
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-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: Safest way to go from x86 to x86_64
Paul Johnson p...@all-the-johnsons.co.uk writes: Is there a safe way to install the x86_64 system over the 32 bit version and then clean off the 32 bit stuff that is no longer needed? There is no safe way to do it, but it IS in fact possible. I have done it twice. It is a lot of work, and I recommend against it. However, where is the fun in life if you do not do something impossible once in a while? First of all you need a 64-bit kernel on there (not so difficult; you can just do rpm -i --ignorearch ...) Then you need to create a repository file containing the relevant 64-bit repositories in /etc/yum.repos.d/. It is a bit difficult getting started because yum will complain about duplicate files when you install some x86_64 packages over i386 packages. You can get around that by letting yum fetch the files and rpm --replacefiles. There is a risk of overwriting something vitally important and rendering the i386 part of your system useless before you have a viable x86_64 system. Have a rescue disk handy. Other challenges can be that you cannot necessarily trust the RPM database to survive the architecture change. You may have to manually remove /var/lib/rpm/__* and do a rebuilddb. Or reinstall from backup if that fails. You will also hit some cases where yum gives up in ways that it asks you to report to the maintainers. I have not actually reported those to the maintainers because I imagine that this is a highly unsupported use of yum. You can get around the problems with rpm --replacefiles and similar tricks. Again, do not do this if you are not prepared to lose all your data. /Benny -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Getopt-ArgvFile] - 661697 rebuild for fixing problems with vendorach/lib
commit 0f58881ac1ff6f643b3e321d873393a8aa0be90a
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 23:07:28 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Getopt-ArgvFile.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Getopt-ArgvFile.spec b/perl-Getopt-ArgvFile.spec
index f131bce..4c32cb3 100644
--- a/perl-Getopt-ArgvFile.spec
+++ b/perl-Getopt-ArgvFile.spec
@@ -1,6 +1,6 @@
Name: perl-Getopt-ArgvFile
Version:1.11
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Interpolates script options from files into @ARGV or another
array
License:Artistic 2.0
Group: Development/Libraries
@@ -55,6 +55,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.11-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun May 02 2010 Marcela Maslanova mmasl...@redhat.com - 1.11-5
- 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: Orphaning all of my packages :(
On Thu, Dec 16, 2010 at 10:55 AM, Toshio Kuratomi a.bad...@gmail.com wrote: The following packages have been orphaned in Fedora 13, 14, and devel: [snip] latexmk -- A make-like utility for LaTeX files Er, hold on there. I'm the maintainer for that package; mef was comaintainer. Anyway, it looks like it is not orphaned in packagedb, so I guess we're okay. More comaintainers are welcome if anyone else would like to pile on. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning all of my packages :(
On Thu, Dec 16, 2010 at 07:40:39PM -0700, Jerry James wrote: On Thu, Dec 16, 2010 at 10:55 AM, Toshio Kuratomi a.bad...@gmail.com wrote: The following packages have been orphaned in Fedora 13, 14, and devel: [snip] latexmk -- A make-like utility for LaTeX files Er, hold on there. I'm the maintainer for that package; mef was comaintainer. Anyway, it looks like it is not orphaned in packagedb, so I guess we're okay. More comaintainers are welcome if anyone else would like to pile on. Ugh -- sorry about that. The actual list of packages was much smaller. The list I posted to this thread included things that mef had acls on, not just things that she was owner of (but what I actually changed i nthe db did not include them). -Toshio pgpOMkHIUoZmd.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
biosdevname v0.3.4
biosdevname, now version 0.3.4. The main visible change is that port indices now start at 1 rather than 0, when assigned by biosdevname (such as falling back to PIRQ) rather explicitly assigned by BIOS. This is in keeping with how the indices are assigned by BIOS on Dell and HP servers. emport where port starts at 1 pcislot#port where port starts at 1 As a side effect, the first VMware Workstation guest NIC now appears as pci3#1 because the virtual machine BIOS exposes the device as being in a PCI slot via PIRQ. This also drops an explicit dependency check on a particular udev version. That version was supposed to properly handle parallel conflicting renames when swizzling within the ethX namespace, but as we've discovered, that doesn't always work. The udev in RHEL5 is older than what we were specifying, but it works just fine, so no more check. Furthermore, if biosdevname somehow messes up (either through its own bug or because of a buggy BIOS), and would assign the same name to two different devices, it won't try to assign names to either (who knows which is correct?). You can see the duplciates when running with the -d debug option. Grab it here: http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz http://linux.dell.com/files/biosdevname/permalink/biosdevname-0.3.4.tar.gz.sign git://linux.dell.com/biosdevname.git I built this today for Fedora rawhide (will be 15), and I encourage other distributions to pick it up as well. shortlog: Matt Domsch (5): require any udev Return nothing if duplicate names would be assigned. Don't assign names to unknown devices only supress duplicates, not all names if any duplicates exist start with port index 1, not index 0 Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Debug-Client] - 661697 rebuild for fixing problems with vendorach/lib
commit f8781e491a929b487052e1c6da637a363e6d671e
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:15:28 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Debug-Client.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Debug-Client.spec b/perl-Debug-Client.spec
index 0405392..e0d89ac 100644
--- a/perl-Debug-Client.spec
+++ b/perl-Debug-Client.spec
@@ -1,6 +1,6 @@
Name: perl-Debug-Client
Version:0.11
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Client side code for perl debugger
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.11-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.11-4
- 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
[perl-Declare-Constraints-Simple] - 661697 rebuild for fixing problems with vendorach/lib
commit 0fed4dea5a5b118b410bb83a87567d799dbf3c5c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:21:05 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Declare-Constraints-Simple.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Declare-Constraints-Simple.spec
b/perl-Declare-Constraints-Simple.spec
index a253154..d235869 100644
--- a/perl-Declare-Constraints-Simple.spec
+++ b/perl-Declare-Constraints-Simple.spec
@@ -1,6 +1,6 @@
Name: perl-Declare-Constraints-Simple
Version:0.03
-Release:9%{?dist}
+Release:10%{?dist}
Summary:Declarative Validation of Data Structures
License:GPL+ or Artistic
Group: Development/Libraries
@@ -67,6 +67,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-10
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-9
- 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
[perl-Devel-CheckOS] - 661697 rebuild for fixing problems with vendorach/lib
commit 83e21f3fca726ebf24d90d8c48eb8fdf26d74bb2
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:36:51 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-CheckOS.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-CheckOS.spec b/perl-Devel-CheckOS.spec
index cc60ea3..ff27e55 100644
--- a/perl-Devel-CheckOS.spec
+++ b/perl-Devel-CheckOS.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-CheckOS
Version:1.63
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Check what OS we're running on
License:GPLv2 or Artistic
Group: Development/Libraries
@@ -67,6 +67,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.63-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Tue Sep 14 2010 Petr Pisar ppi...@redhat.com - 1.63-1
- 1.63 bump
- Remove `dontask' patch as interactive code is not run anymore
--
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-Devel-Cover] - 661697 rebuild for fixing problems with vendorach/lib
commit f111fe443f7cc57976e2436b061e7d58e6b9b505
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:42:32 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Cover.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Cover.spec b/perl-Devel-Cover.spec
index 34e25ea..de25eb9 100644
--- a/perl-Devel-Cover.spec
+++ b/perl-Devel-Cover.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Cover
Version:0.66
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Code coverage metrics for Perl
Group: Development/Libraries
@@ -64,6 +64,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.66-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.66-1
- Mass rebuild with perl-5.12.0 update
--
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-Devel-Cycle] - 661697 rebuild for fixing problems with vendorach/lib
commit 271c183a6e6a7218465a31595c6609f365dc25a7
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:48:47 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Cycle.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Cycle.spec b/perl-Devel-Cycle.spec
index 91b7906..e5aaca6 100644
--- a/perl-Devel-Cycle.spec
+++ b/perl-Devel-Cycle.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Cycle
Version:1.11
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Find memory cycles in objects
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.11-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.11-4
- 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
[perl-Devel-Declare] - 661697 rebuild for fixing problems with vendorach/lib
commit 8c61d208406f8fad5d8003379b0d0682b10c217e
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:53:52 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Declare.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Declare.spec b/perl-Devel-Declare.spec
index 696452d..1c7905b 100644
--- a/perl-Devel-Declare.spec
+++ b/perl-Devel-Declare.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Declare
Version:0.006000
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Adding keywords to perl, in perl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.006000-3
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sat Jul 17 2010 Iain Arnell iarn...@gmail.com 0.006000-2
- cleanup spec for moderm rpmbuild
- BR perl(B::Compiling)
--
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-Devel-Dumpvar] - 661697 rebuild for fixing problems with vendorach/lib
commit 8bbd876b648d94a0419927363efd7b9d447a4b74
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 09:59:07 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Dumpvar.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Dumpvar.spec b/perl-Devel-Dumpvar.spec
index 963bf21..8b7f8d3 100644
--- a/perl-Devel-Dumpvar.spec
+++ b/perl-Devel-Dumpvar.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Dumpvar
Version:1.06
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Pure-OO reimplementation of dumpvar.pl
License:GPL+ or Artistic
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.06-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Tue Sep 14 2010 Petr Pisar ppi...@redhat.com - 1.06-1
- 1.06 bump
--
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-Devel-FastProf] - 661697 rebuild for fixing problems with vendorach/lib
commit 32a5bd1c1f3d725c54930662f076480b487621a0
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:04:30 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-FastProf.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-FastProf.spec b/perl-Devel-FastProf.spec
index a53bcd8..f8c48bd 100644
--- a/perl-Devel-FastProf.spec
+++ b/perl-Devel-FastProf.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-FastProf
Version:0.08
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Fast perl per-line profiler
License:GPL+ or Artistic
Group: Development/Libraries
@@ -70,6 +70,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.08-5
- 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
[perl-Devel-FindRef] - 661697 rebuild for fixing problems with vendorach/lib
commit 609c7da7c1aa82e6c5c4b1779f1910ac705ef0de
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:10:11 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-FindRef.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-FindRef.spec b/perl-Devel-FindRef.spec
index 2efe51a..4c49a30 100644
--- a/perl-Devel-FindRef.spec
+++ b/perl-Devel-FindRef.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-FindRef
Version:1.42
-Release:10%{?dist}
+Release:11%{?dist}
Summary:Where is that reference to my variable hiding?
License:GPL+ or Artistic
Group: Development/Libraries
@@ -50,6 +50,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/Devel*.3*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 1.42-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 1.42-10
- 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
[perl-Devel-GlobalDestruction] - 661697 rebuild for fixing problems with vendorach/lib
commit 9effa62321470bb326feb8fe600383f5813b8d9c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:16:20 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-GlobalDestruction.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-GlobalDestruction.spec
b/perl-Devel-GlobalDestruction.spec
index ca07eb1..0f62df8 100644
--- a/perl-Devel-GlobalDestruction.spec
+++ b/perl-Devel-GlobalDestruction.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-GlobalDestruction
Version:0.02
-Release:10%{?dist}
+Release:11%{?dist}
# see lib/Devel/GlobalDestruction.pm
License:GPL+ or Artistic
Group: Development/Libraries
@@ -62,6 +62,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.02-11
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.02-10
- 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
[perl-Devel-Hide] - 661697 rebuild for fixing problems with vendorach/lib
commit ee1d4c4d9f1d9d77c7651f30b87b874a78b79d27
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:22:00 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Hide.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Hide.spec b/perl-Devel-Hide.spec
index 2afa7c9..9b3e5be 100644
--- a/perl-Devel-Hide.spec
+++ b/perl-Devel-Hide.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Hide
Version:0.0008
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Forces the unavailability of specified Perl modules (for
testing)
License:GPL+ or Artistic
Group: Development/Libraries
@@ -49,6 +49,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.0008-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.0008-5
- 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
[perl-Devel-Leak] - 661697 rebuild for fixing problems with vendorach/lib
commit 1a9d6fd57a3ceeaed4d9abdcd369b9b424284fd9
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:27:35 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Leak.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Leak.spec b/perl-Devel-Leak.spec
index a77dd2f..03d904f 100644
--- a/perl-Devel-Leak.spec
+++ b/perl-Devel-Leak.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Leak
Version:0.03
-Release:12%{?dist}
+Release:13%{?dist}
Summary:Utility for looking for perl objects that are not reclaimed
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-13
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.03-12
- 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
[perl-Devel-LeakGuard-Object] - 661697 rebuild for fixing problems with vendorach/lib
commit cf10fdd5a40dec444ed4afbe1fe224154e63336c
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:33:40 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-LeakGuard-Object.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-LeakGuard-Object.spec b/perl-Devel-LeakGuard-Object.spec
index d8746ea..d0b33a4 100644
--- a/perl-Devel-LeakGuard-Object.spec
+++ b/perl-Devel-LeakGuard-Object.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-LeakGuard-Object
Version:0.06
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Scoped checks for object leaks
License:GPL+ or Artistic
Group: Development/Libraries
@@ -46,6 +46,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.06-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.06-4
- 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
[perl-Devel-LexAlias] - 661697 rebuild for fixing problems with vendorach/lib
commit 55cd5d0ed5580bdbdb0ce442face2b473e05bc77
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:38:37 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-LexAlias.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-LexAlias.spec b/perl-Devel-LexAlias.spec
index 7ed404b..4b06ffb 100644
--- a/perl-Devel-LexAlias.spec
+++ b/perl-Devel-LexAlias.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-LexAlias
Version:0.04
-Release:8%{?dist}
+Release:9%{?dist}
Summary:Alias lexical variables
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-9
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.04-8
- 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
[perl-Devel-PartialDump] - 661697 rebuild for fixing problems with vendorach/lib
commit b19ef2aceafb08fc6b595874165335d1f6f3a9df
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:44:10 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-PartialDump.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-PartialDump.spec b/perl-Devel-PartialDump.spec
index b35ac6c..97c9803 100644
--- a/perl-Devel-PartialDump.spec
+++ b/perl-Devel-PartialDump.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-PartialDump
Version:0.13
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Partial dumping of data structures, optimized for argument
printing
# from PartialDump.pm
License:GPL+ or Artistic
@@ -53,5 +53,8 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.13-2
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Sun Jul 04 2010 Iain Arnell iarn...@gmail.com 0.13-1
- Specfile autogenerated by cpanspec 1.78.
--
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 561389] amavisd-new always reports Shutting down amavisd: Daemon [19248] terminated by SIGTERM
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=561389 Dennis Krul d...@krul.nu changed: What|Removed |Added CC||d...@krul.nu --- Comment #16 from Dennis Krul d...@krul.nu 2010-12-16 04:45:18 EST --- This issue seems to be still present on Fedora 13 with this patch: # rpm -qv amavisd-new amavisd-new-2.6.4-2.fc13.noarch # service amavisd restart Shutting down amavisd: Daemon [23352] terminated by SIGTERM [ OK ] amavisd stopped Starting amavisd: [ OK ] I still receive mails from cron when sa-update restarts amavisd. -- 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
[perl-Devel-Refactor] - 661697 rebuild for fixing problems with vendorach/lib
commit 606a39dec2cf2ea35f22aec5e15cf537d2d74065
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 10:55:00 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Refactor.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Refactor.spec b/perl-Devel-Refactor.spec
index 09c7bb1..964da19 100644
--- a/perl-Devel-Refactor.spec
+++ b/perl-Devel-Refactor.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Refactor
Version:0.05
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Perl extension for refactoring Perl code
License:GPL+ or Artistic
Group: Development/Libraries
@@ -45,6 +45,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-5
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.05-4
- 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
[perl-Devel-Refcount] - 661697 rebuild for fixing problems with vendorach/lib
commit 282a8ced2742ce805bc78679142e215df68e20fb
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 11:00:17 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Refcount.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Refcount.spec b/perl-Devel-Refcount.spec
index a4cea34..4b8b0be 100644
--- a/perl-Devel-Refcount.spec
+++ b/perl-Devel-Refcount.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Refcount
Version:0.07
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Obtain the REFCNT value of a referent
License:GPL+ or Artistic
Group: Development/Libraries
@@ -47,6 +47,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.07-4
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.07-3
- 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
[perl-Devel-Size] - 661697 rebuild for fixing problems with vendorach/lib
commit 73bb8ad1c9d23bb482c0357b65e27af55030c9a2
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 11:05:55 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-Size.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-Size.spec b/perl-Devel-Size.spec
index 51f34e4..075ee45 100644
--- a/perl-Devel-Size.spec
+++ b/perl-Devel-Size.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-Size
Version:0.71
-Release:5%{?dist}
+Release:6%{?dist}
Summary:Perl extension for finding the memory usage of Perl variables
License:GPL+ or Artistic
Group: Development/Libraries
@@ -66,6 +66,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 0.71-6
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 0.71-5
- 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
[perl-Devel-SmallProf] - 661697 rebuild for fixing problems with vendorach/lib
commit d2221b0de5739ae49305d2c664bff9b0f5dc148b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Thu Dec 16 11:10:50 2010 +0100
- 661697 rebuild for fixing problems with vendorach/lib
perl-Devel-SmallProf.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Devel-SmallProf.spec b/perl-Devel-SmallProf.spec
index cc78b09..c09a650 100644
--- a/perl-Devel-SmallProf.spec
+++ b/perl-Devel-SmallProf.spec
@@ -1,6 +1,6 @@
Name: perl-Devel-SmallProf
Version:2.02
-Release:7%{?dist}
+Release:8%{?dist}
Summary:Per-line Perl profiler
License:GPL+ or Artistic
Group: Development/Libraries
@@ -61,6 +61,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
+* Thu Dec 16 2010 Marcela Maslanova mmasl...@redhat.com - 2.02-8
+- 661697 rebuild for fixing problems with vendorach/lib
+
* Fri Apr 30 2010 Marcela Maslanova mmasl...@redhat.com - 2.02-7
- 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
