[Test-Announce] 2011-08-29 @ 15:00 UTC - Fedora QA Meeting
WHAT: Fedora QA Meeting WHEN: 15:00 UTC (11:00 EDT, 08:00 PDT) WHERE: #fedora-meeting Tomorrow (or today...) is QA meeting time again. This week's meeting will be brought to you by j_dulaney, but I'm sending the announcement. The agenda looks scarily like last week's because the test week got pushed back! Please propose any further topics by reply and we'll add them to the agenda, or just bring them up in the open discussion. Thanks everyone! Proposed agenda: * Previous meeting follow-up * Beta preparation * l10n / i18n test week * AutoQA update * Open discussion -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list t...@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[HEADS UP] remove ddate(1) command from rawhide
I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gimp
On 08/25/2011 05:28 PM, Nils Philippsen wrote: You're probably referring to the updates 2.2-2.4 in '07 and 2.4-2.6 in '08 but please keep in mind that we're stuck with 2.6.x as the stable branch since then, so there's no reason to be gloomy about the Fedora side just yet. I remember how we tracked the 2.3-2.4 development in Rawhide, which allowed me at the time to write articles (previews, tutorials) based on our official packages and, of course, allowed the entire community to contribute with testing and feedback. While we mightn't have had an explicit update policy for Fedora in the time, these packages only went in after thorough testing on top of that upstream managed to keep things as backwards-compatible as could be expected -- the built-in scheme interpreter became a bit more strict in 2.6, which was a documented break with 2.4 which could easily be fixed by fixing affected 3rd party scripts. Testing is the magic word, we want to test it. Considering that upstream to a large part isn't interested in working on 2.6 anymore -- the last commit by a core developer to this branch was in February this year -- I don't expect to see another 2.6 bugfix release. As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course (which I already do to a certain extent, I can e.g. confirm that the ufraw gimp plugin built with 2.6 works with a private installation of current git master). In the meantime I feel there is some duplicate effort wasted here: the maintainer (Nils) is doing his own testing in private, another contributor (Luya) is struggling (and hitting walls) with building an external repo, people don't know what and from where to use. -- nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.? If it is maintained, and works then it should stay. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.? If it is maintained, and works then it should stay. +1. I don't use vim or rythmbox or play tremulous, and their presence doesn't hurt me or my mirror. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 07:25:18 -0500, JC (Jon) wrote: On Monday, August 29, 2011, 7:54:10 AM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Why does it matter to you? Why make this change, which will at best inconvenience that very small minority of Feedora users.? If it is maintained, and works then it should stay. +1. I don't use vim or rythmbox or play tremulous, and their presence doesn't hurt me or my mirror. :) $ rpm -qf /usr/bin/ddate util-linux-2.19.1-1.4.fc15.x86_64 As such it is part of every installation. It could be optional instead. $ man ddate [...] |NOTE | After `X-Day' passed without incident, the Church of the SubGenius | declared that it had got the year upside down - X-Day is actually in | 8661 AD rather than 1998 AD. Thus, the True X-Day is Cfn 40, 9827. [...] Strange humor to install something like that in a util-linux package. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20110829 changes
Compose started at Mon Aug 29 08:15:12 UTC 2011 Broken deps for x86_64 -- FlightGear-2.0.0-6.fc16.x86_64 requires libosgViewer.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgUtil.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgText.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgSim.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgGA.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgFX.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) FlightGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) SimGear-2.0.0-6.fc16.i686 requires libosgParticle.so.74 SimGear-2.0.0-6.fc16.i686 requires libosgDB.so.74 SimGear-2.0.0-6.fc16.i686 requires libosg.so.74 SimGear-2.0.0-6.fc16.i686 requires libOpenThreads.so.11 SimGear-2.0.0-6.fc16.x86_64 requires libosgParticle.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosgDB.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libosg.so.74()(64bit) SimGear-2.0.0-6.fc16.x86_64 requires libOpenThreads.so.11()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.8.0-2.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) 1:anerley-0.3.0-2.fc17.i686 requires libcamel-1.2.so.28 1:anerley-0.3.0-2.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) bluetile-0.5.3-11.fc16.x86_64 requires libHShslogger-1.1.4-ghc7.0.4.so()(64bit) bluetile-0.5.3-11.fc16.x86_64 requires ghc(xmonad-contrib-0.9.2) = 0:d669bbdb9b9f7adb145fcb61825dec73 bluetile-0.5.3-11.fc16.x86_64 requires ghc(hslogger-1.1.4) = 0:b19530ddf428e57c988347097f958882 cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contacts-0.12-10.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet dh-make-0.55-3.fc15.noarch requires debhelper ekiga-3.3.1-3.fc17.x86_64 requires libpt.so.2.10.1()(64bit) ekiga-3.3.1-3.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) empathy-3.1.5.1-2.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) evolution-couchdb-0.5.91-2.fc17.x86_64 requires libcamel-provider-1.2.so.28()(64bit) evolution-couchdb-0.5.91-2.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) evolution-rss-0.2.90-28.20110818git.fc17.x86_64 requires libcamel-provider-1.2.so.28()(64bit) evolution-rss-0.2.90-28.20110818git.fc17.x86_64 requires libcamel-1.2.so.28()(64bit) exaile-0.3.2.1-1.fc16.noarch requires
Re: [HEADS UP] remove ddate(1) command from rawhide
On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content The Julian and Gregorian calendars are also of religious origin. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-POE-Server-TCP/el6] first EPEL-6 build
commit a184a72b487bda28b1125cec1cd0fbbf5cb5b5d8
Author: remi fed...@famillecollet.com
Date: Mon Aug 29 15:31:37 2011 +0200
first EPEL-6 build
perl-Test-POE-Server-TCP.spec |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
---
diff --git a/perl-Test-POE-Server-TCP.spec b/perl-Test-POE-Server-TCP.spec
index bfe92dc..00ee3e1 100644
--- a/perl-Test-POE-Server-TCP.spec
+++ b/perl-Test-POE-Server-TCP.spec
@@ -1,6 +1,6 @@
Name: perl-Test-POE-Server-TCP
Version:1.16
-Release:2%{?dist}
+Release:1%{?dist}
Summary:POE Component providing TCP server services for test cases
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,8 +57,8 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/*
%changelog
-* Tue Jul 19 2011 Petr Sabata con...@redhat.com - 1.16-2
-- Perl mass rebuild
+* Fri Aug 26 2011 Remi Collet r...@fedoraproject.org - 1.16-1
+- first EPEL-6 build
* Wed Jun 29 2011 Yanko Kaneti yan...@declera.com 1.16-1
- Latest upstream release - 1.16
--
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 733820] Please build for EPEL-6
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=733820 Yanko Kaneti yan...@declera.com changed: What|Removed |Added AssignedTo|yan...@declera.com |fed...@famillecollet.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: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote: On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content The Julian and Gregorian calendars are also of religious origin. Apples and oranges. Do you find anything like in the SEE ALSO section of man ddate also in man date? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 733820] Please build for EPEL-6
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=733820 --- Comment #1 from Fedora Update System upda...@fedoraproject.org 2011-08-29 09:43:07 EDT --- perl-Test-POE-Server-TCP-1.16-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Test-POE-Server-TCP-1.16-1.el6 -- 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: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 08:32:01 -0500, JC (Jon) wrote: On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content The Julian and Gregorian calendars are also of religious origin. Apples and oranges. Do you find anything like in the SEE ALSO section of man ddate also in man date? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 728668] Please build for EPEL-6
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=728668 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-08-29 09:44:28 EDT --- perl-POE-Component-Client-HTTP-0.895-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-POE-Component-Client-HTTP-0.895-1.el6 -- 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 728668] Please build for EPEL-6
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=728668 Remi Collet fed...@famillecollet.com changed: What|Removed |Added AssignedTo|cw...@alumni.drew.edu |fed...@famillecollet.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
[Bug 728669] Please build for EPEL-6
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=728669 Remi Collet fed...@famillecollet.com changed: What|Removed |Added AssignedTo|cw...@alumni.drew.edu |fed...@famillecollet.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
[Bug 728667] Please build for EPEL-6
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=728667 --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2011-08-29 09:46:58 EDT --- perl-POE-Component-Client-DNS-1.051-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-POE-Component-Client-DNS-1.051-1.el6 -- 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 728667] Please build for EPEL-6
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=728667 Remi Collet fed...@famillecollet.com changed: What|Removed |Added AssignedTo|cw...@alumni.drew.edu |fed...@famillecollet.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: [HEADS UP] remove ddate(1) command from rawhide
On 08/29/2011 05:24 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On 08/29/2011 05:24 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved? Acceptable to me, but is the extra metadata for another RPM worth the space savings? -J Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
libtool rebuild required for updates-testing
currently updates-testing offers GVV 4.6.1 (thank you!) but libtool needs a rebuild for dependencies this time the rebuild runs on my testing-VM to rebuild all my packages later on this machine with new GCC, but this should also be in updates-testing signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram methe...@gmail.com wrote: Otherwise, make ddate a sub package and don't install it by default. Solved? As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip. So I think Fedora shouldn't be more willing to strip ddate than it would be willing to patch out ddate functionality if it were embedded in 'hwclock'. There is a reasonable argument that util-linux ought to go on a diet: Right now it appears to take up 6424k on disk. (Though, most of that is localizations— and several of the various NEWS/readme files it includes are bigger than ddate, as is its copy of the GPL. This silly thread has probably taken up more disk space than ddate, or it soon will) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
Once upon a time, Jon Ciesla l...@jcomserv.net said: On 08/29/2011 05:24 PM, Karel Zak wrote: IIRC, you are upstream for this and could do this change upstream and then, there wouldn't be a debate about this here. Otherwise, make ddate a sub package and don't install it by default. Solved? Acceptable to me, but is the extra metadata for another RPM worth the space savings? Is that why this is being done? Space savings? On my F15 system, ddate, the README, and the manual pages account for 22k. If space is the justification, there's lots of better places to start. Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? How many tools do we really need for partitioning disks and managing partitions (util-linux has fdisk, sfdisk, cfdisk, partx, blockdev, all with associated documentation)? Note: I am NOT saying any of that should be removed. I'm just saying that space savings as justification of removing ddate is stupid. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram methe...@gmail.com wrote: Â Otherwise, Â make ddate a sub package and don't install it by default. Â Solved? As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip. So I think Fedora shouldn't be more willing to strip ddate than it would be willing to patch out ddate functionality if it were embedded in 'hwclock'. There is a reasonable argument that util-linux ought to go on a diet: Right now it appears to take up 6424k on disk. (Though, most of that is localizationsâ and several of the various NEWS/readme files it includes are bigger than ddate, as is its copy of the GPL. This silly thread has probably taken up more disk space than ddate, or it soon will) I think it has. :) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-DateTime-Format-Epoch] initial import (rhbz#730043)
commit 283b2e9603b64f88c650f5f0e5f49ee7f5db86a2
Author: Iain Arnell iarn...@gmail.com
Date: Mon Aug 29 16:30:34 2011 +0200
initial import (rhbz#730043)
.gitignore |1 +
perl-DateTime-Format-Epoch.spec | 54 +++
sources |1 +
3 files changed, 56 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..0f0a757 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/DateTime-Format-Epoch-0.13.tar.gz
diff --git a/perl-DateTime-Format-Epoch.spec b/perl-DateTime-Format-Epoch.spec
new file mode 100644
index 000..87b58b5
--- /dev/null
+++ b/perl-DateTime-Format-Epoch.spec
@@ -0,0 +1,54 @@
+Name: perl-DateTime-Format-Epoch
+Version:0.13
+Release:1%{?dist}
+Summary:Convert DateTimes to/from epoch seconds
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/DateTime-Format-Epoch/
+Source0:
http://www.cpan.org/modules/by-module/DateTime/DateTime-Format-Epoch-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl = 0:5.00503
+BuildRequires: perl(DateTime) = 0.31
+BuildRequires: perl(Math::BigInt) = 1.66
+BuildRequires: perl(Module::Build)
+BuildRequires: perl(Params::Validate)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+Requires: perl(DateTime) = 0.31
+Requires: perl(Math::BigInt) = 1.66
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This module can convert a DateTime object (or any object that can be
+converted to a DateTime object) to the number of seconds since a given
+epoch. It can also do the reverse.
+
+%prep
+%setup -q -n DateTime-Format-Epoch-%{version}
+
+# replace CRLF
+find -type f -print0 | xargs -0 sed -i 's/\r$//'
+
+%build
+%{__perl} Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=%{buildroot} create_packlist=0
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+./Build test
+
+%files
+%doc Changes LICENSE README TODO
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Aug 11 2011 Iain Arnell iarn...@gmail.com 0.13-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..737cea8 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+f42982ea634401df953f88ce5eec1b7d DateTime-Format-Epoch-0.13.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-DateTime-Format-Epoch/f16] initial import (rhbz#730043)
Summary of changes: 283b2e9... initial import (rhbz#730043) (*) (*) This commit already existed in another branch; no separate mail sent -- 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-DateTime-Format-Epoch/f15] initial import (rhbz#730043)
Summary of changes: 283b2e9... initial import (rhbz#730043) (*) (*) This commit already existed in another branch; no separate mail sent -- 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: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Chris Adams wrote: Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? Why does it have any floppy tools any more? The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Chris Adams wrote: Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? Why does it have any floppy tools any more? The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Because there are still people with floppy drives? -J -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Mon, Aug 29, 2011 at 09:44:33AM -0500, Jon Ciesla wrote: Because there are still people with floppy drives? +1 It's ridiculous to think that older HW doesn't exist because systems with that HW are not sold anymore (I don't even know id the latter is true at all -- some special purpose systems might still have it). We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore. Don't let us all fall in the GNOME3 trap (assuming that all hardware now has accelerated graphics support, which is even more ridiculous, although GNOME3 has become useless for most people I know anyway). Sorry, I couldn't resist... -- --Jos Vos j...@xos.nl --X/OS Experts in Open Systems BV | Phone: +31 20 6938364 --Amsterdam, The Netherlands| Fax: +31 20 6948204 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote: That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it... If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. - it's joke rather than anything useful - it's installed on all systems, but almost nobody uses this crap Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote: The Julian and Gregorian calendars are also of religious origin. Apples and oranges. Do you find anything like in the SEE ALSO section of man ddate also in man date? That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. With that point of view, it's probably impossible to convince you. I won't try. I just encourage Karel to get rid of ddate somehow. A valid reason IMO is to build a base distribution, a product -- our product -- which does not consist of extremely silly code and which does not advertise dubious religions. Not even with links as found in the manual. There are several scenarios where we divert from upstream due to various circumstances. Whether it's harmful to distribute ddate, I don't know. Isn't it enough reason to not offer something because it's considered silly/crazy crap? Or if it doesn't make sense to ship it as part of a default OS environment? http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar | Most common Linux operating system-distributions have the command ddate | to show the current Discordian date. Strange people these Linux people. http://en.wikipedia.org/wiki/Discordian_calendar#Implementations | ddate, a program that prints the current date in the Discordian calendar, | is part of the util-linux package of basic system utilities.[6] As such, | it is included in nearly all Linux distributions, despite some | resistance.[7] There are many other programs with similar functionality. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149321 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Jos Vos wrote: We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore. No. You're making an apples to orange comparison. Just like Jon has done this whole thread. This bike shedding as gone on long enough. Remove ddate. Karel, you're upstream. Do it. P.S. Your argument will be moot when the kernel drops the floppy module. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On 08/29/2011 05:00 PM, Karel Zak wrote: On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote: That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it... If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. - it's joke rather than anything useful Then have upstream remove it from _their_ sources. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
On Mon, Aug 29, 2011 at 09:37:37AM -0500, Michael Cronenworth wrote: Chris Adams wrote: Why does util-linux have two floppy disk formatters (/usr/bin/floppy and /usr/sbin/fdformat)? Why does it have any floppy tools any more? because we still support floppy devices? The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases. Does it mean that modprobe floppy does not work? Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 08:47:40AM -0500, Jon Ciesla wrote: That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. That's simple, I'm upstream maintainer. The command has been disabled by default in the last stable release. And yes, one I day I'll drop it... If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. - it's joke rather than anything useful - it's installed on all systems, but almost nobody uses this crap Really? How do you know that? -J Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 08:47:40 -0500, JC (Jon) wrote: The Julian and Gregorian calendars are also of religious origin. Apples and oranges. Do you find anything like in the SEE ALSO section of man ddate also in man date? That may be (both are human constructs, it's like say hey, that's made up word!, but no, I don't. My point is simply that while it is extremely silly code, it is in fact code provided by upstream. It's still maintained, is of a valid license, and I don't see a valid reason to break with upstream here. If you can convince upstream to split it out or drop it, great. If not, and there isn't a compelling disk space or security argument, I really don't see why this should be dropped. I'm looking for a clear example of demonstrable harm. It's 14k of silliness, not a rootkit. With that point of view, it's probably impossible to convince you. I won't try. I just encourage Karel to get rid of ddate somehow. A valid reason IMO is to build a base distribution, a product -- our product -- which does not consist of extremely silly code and which does not advertise dubious religions. Not even with links as found in the manual. There are several scenarios where we divert from upstream due to various circumstances. Sure, for sufficient reasons. Whether it's harmful to distribute ddate, I don't know. Isn't it enough reason to not offer something because it's considered silly/crazy crap? Or if it doesn't make sense to ship it as part of a default OS environment? I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply gosh, I don't sue that, so. . .. Otherwise we'll start dropping games. http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar | Most common Linux operating system-distributions have the command ddate | to show the current Discordian date. Strange people these Linux people. http://en.wikipedia.org/wiki/Discordian_calendar#Implementations | ddate, a program that prints the current date in the Discordian calendar, | is part of the util-linux package of basic system utilities.[6] As such, | it is included in nearly all Linux distributions, despite some | resistance.[7] There are many other programs with similar functionality. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=149321 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
Jos Vos wrote: We just have to wait till people come up with the argument that serial or parallel ports don't exist anymore. No. You're making an apples to orange comparison. Just like Jon has done this whole thread. This bike shedding as gone on long enough. Playing devil's advocate != bikeshedding. But, I agree that this discussion is aging rapidly. Remove ddate. Karel, you're upstream. Do it. Now *this* makes sense. I never advocated ddate being preserved in lucite forevermore. I just wanted a sane reason to deviate from upstream. if upstream drops it, the point is moot, and I think that's fine. P.S. Your argument will be moot when the kernel drops the floppy module. Is there actually a plan for this to happen? Curious, not arguing here. -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- 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
Broken dependencies: perl-NOCpulse-Gritch
perl-NOCpulse-Gritch has broken dependencies in the F-16 tree: On x86_64: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-NOCpulse-Gritch-1.27.9-1.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-WWW-Mechanize-Catalyst-0.54.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Test-WWW-Mechanize-Catalyst: d4c69191f5e622b4c2e840cd4feaf629 Test-WWW-Mechanize-Catalyst-0.54.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-WWW-Mechanize-Catalyst] update to 0.54
commit 6cc6556fd0dcb5d64fea9a1fbd3972f69c900d69
Author: Iain Arnell iarn...@gmail.com
Date: Mon Aug 29 17:51:04 2011 +0200
update to 0.54
.gitignore|1 +
perl-Test-WWW-Mechanize-Catalyst.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 4ddb380..a628574 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Test-WWW-Mechanize-Catalyst-0.52.tar.gz
/Test-WWW-Mechanize-Catalyst-0.53.tar.gz
+/Test-WWW-Mechanize-Catalyst-0.54.tar.gz
diff --git a/perl-Test-WWW-Mechanize-Catalyst.spec
b/perl-Test-WWW-Mechanize-Catalyst.spec
index 5bd0871..13f26d5 100644
--- a/perl-Test-WWW-Mechanize-Catalyst.spec
+++ b/perl-Test-WWW-Mechanize-Catalyst.spec
@@ -1,7 +1,7 @@
Name: perl-Test-WWW-Mechanize-Catalyst
Summary:Test::WWW::Mechanize for Catalyst
-Version:0.53
-Release:3%{?dist}
+Version:0.54
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/B/BO/BOBTFISH/Test-WWW-Mechanize-Catalyst-%{version}.tar.gz
@@ -64,6 +64,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Aug 29 2011 Iain Arnell iarn...@epo.org 0.54-1
+- update to latest upstream version
+
* Thu Jul 21 2011 Petr Sabata con...@redhat.com - 0.53-3
- Perl mass rebuild
diff --git a/sources b/sources
index 8e05f61..ef830fb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e0ea83d3708d044f9beb670d117f9376 Test-WWW-Mechanize-Catalyst-0.53.tar.gz
+d4c69191f5e622b4c2e840cd4feaf629 Test-WWW-Mechanize-Catalyst-0.54.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-WWW-Mechanize-Catalyst/f16] update to 0.54
Summary of changes: 6cc6556... update to 0.54 (*) (*) This commit already existed in another branch; no separate mail sent -- 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: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote: I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply gosh, I don't sue that, so. . .. Otherwise we'll start dropping games. Sure (and not limited to games, which are in optional packages, however). We do that all the time, if a package maintainer no longer considers a game (or package in general) worthwhile, and if nobody else volunteers to take over a package. Of course, you're free to adapt as many orphans as you like, whether actively maintained upstream or ancient. Eventually, you'll be in the same situation, where you would like to drop something, be it a completely optional package or a plugin [*] you consider useless, close to useless, or just broken. [*] or a program with alternative user-interfaces -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-16 Branched report: 20110829 changes
Compose started at Mon Aug 29 13:15:28 UTC 2011 Broken deps for x86_64 -- 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpagent.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmpmibs.so.25()(64bit) 389-ds-base-1.2.9.0-1.fc16.2.x86_64 requires libnetsnmp.so.25()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) almanah-0.7.3-12.fc16.x86_64 requires libcamel-1.2.so.26()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserverui-3.0.so.0()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libecal-1.2.so.9()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) almanah-0.7.3-12.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.i686 requires libedataserver-1.2.so.14 1:anerley-0.3.0-1.fc16.i686 requires libebook-1.2.so.11 1:anerley-0.3.0-1.fc16.x86_64 requires libebook-1.2.so.11()(64bit) 1:anerley-0.3.0-1.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) awn-extras-applets-0.4.2-0.1.bzr1523.fc16.x86_64 requires libgnome-menu.so.2()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libebook-1.2.so.10()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires gnome-python2-applet deskbar-applet-2.32.0-4.fc15.x86_64 requires libcamel-1.2.so.23()(64bit) deskbar-applet-2.32.0-4.fc15.x86_64 requires libedataserver-1.2.so.14()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave emerillon-0.1.2-17.fc16.x86_64 requires libethos-ui-1.0.so.0()(64bit) emerillon-0.1.2-17.fc16.x86_64 requires libethos-1.0.so.0()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) evolution-rss-0.2.90-25.20110716git.fc16.x86_64 requires libebook-1.2.so.11()(64bit) exaile-0.3.2.1-1.fc16.noarch requires hal fawkes-guis-0.4.2-4.fc16.i686 requires libgvc.so.5 fawkes-guis-0.4.2-4.fc16.i686 requires libcdt.so.4 fawkes-guis-0.4.2-4.fc16.i686 requires libgraph.so.4 fawkes-guis-0.4.2-4.fc16.x86_64 requires libgvc.so.5()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libcdt.so.4()(64bit) fawkes-guis-0.4.2-4.fc16.x86_64 requires libgraph.so.4()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libboost_thread-mt.so.1.46.1()(64bit) fawkes-plugin-player-0.4.2-4.fc16.x86_64 requires libgeos-3.2.1.so()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libedataserver-1.2.so.14()(64bit) ffgtk-plugin-evolution-0.7.94-5.fc16.x86_64 requires libebook-1.2.so.11()(64bit) file-browser-applet-0.6.6-1.fc15.x86_64 requires libpanel-applet-2.so.0()(64bit) flaw-1.2.4-2.fc15.x86_64 requires libSDL_gfx.so.0()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk_images.so.1.1()(64bit) fldigi-3.21.7-1.fc16.x86_64 requires libfltk.so.1.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_system-mt.so.1.46.1()(64bit) flush-0.9.10-3.fc16.x86_64 requires libboost_signals-mt.so.1.46.1()(64bit)
Re: gimp
On Mon, 2011-08-29 at 15:03 +0300, Nicu Buculei wrote: On 08/25/2011 05:28 PM, Nils Philippsen wrote: You're probably referring to the updates 2.2-2.4 in '07 and 2.4-2.6 in '08 but please keep in mind that we're stuck with 2.6.x as the stable branch since then, so there's no reason to be gloomy about the Fedora side just yet. I remember how we tracked the 2.3-2.4 development in Rawhide, which allowed me at the time to write articles (previews, tutorials) based on our official packages and, of course, allowed the entire community to contribute with testing and feedback. We didn't track development at that time, these were release candidates of 2.4, see the RPM changelog: ... * Wed Oct 24 2007 Nils Philippsen nphil...@redhat.com - 2:2.4.0-1 ... * Fri Sep 07 2007 Nils Philippsen nphil...@redhat.com - 2:2.4.0-0.rc3.2 ... * Fri Sep 07 2007 Nils Philippsen nphil...@redhat.com - 2:2.4.0-0.rc3.1 ... * Fri Sep 07 2007 Nils Philippsen nphil...@redhat.com - 2:2.4.0-0.rc2.2 ... * Tue Sep 04 2007 Nils Philippsen nphil...@redhat.com - 2:2.4.0-0.rc2.1 ... * Thu Aug 16 2007 Nils Philippsen nphil...@redhat.com - 2:2.4.0-0.rc1.1 ... * Fri Jul 13 2007 Nils Philippsen nphil...@redhat.com - 2:2.2.17-1 ... These versions already used the same file names as proper 2.4.x did, right now I know that much of this _will_ change when 2.8 is released, which incidentally impacts packaging the most (rather than normal code changes). While we mightn't have had an explicit update policy for Fedora in the time, these packages only went in after thorough testing on top of that upstream managed to keep things as backwards-compatible as could be expected -- the built-in scheme interpreter became a bit more strict in 2.6, which was a documented break with 2.4 which could easily be fixed by fixing affected 3rd party scripts. Testing is the magic word, we want to test it. Foremost, I want to have packages tested that actually have a more than even chance of ending up in the stable release. Right now I don't feel as confident about getting 2.8 in time for F-17 as I felt about 2.4 for F-8. If you look at the development schedule on http://tasktaste.com/projects/Enselic/gimp-2-8 you'll notice some fairly sizable tasks left which account for 15-18 workdays of people who'll likely do this in their spare time, which is projected right now for about 81 realtime days from now. I haven't seen much activity on the listed topics though in the last time (not critiquing upstream devs here, I'm a bit surprised to see only 2 real tasks left on that schedule), so this might slip even a bit more. It's ready when it's ready and all that. Rest assured that I'll push packages when we get to a point where inclusion is probable. Considering that upstream to a large part isn't interested in working on 2.6 anymore -- the last commit by a core developer to this branch was in February this year -- I don't expect to see another 2.6 bugfix release. As well, installing both stable versions side-by-side isn't an option as you can't install them into the same prefix: the libraries have the same SONAME, the new ones are expected to be ABI compatible. Therefore I don't see a real alternative to rebasing to 2.8 in stable Fedora releases when it finally is available, after thoroughly testing it of course (which I already do to a certain extent, I can e.g. confirm that the ufraw gimp plugin built with 2.6 works with a private installation of current git master). In the meantime I feel there is some duplicate effort wasted here: the maintainer (Nils) is doing his own testing in private, another contributor (Luya) is struggling (and hitting walls) with building an external repo, people don't know what and from where to use. I'll think about making gimp-beta packages and putting them on fedorapeople, but their relevance for testing in Fedora will be rather limited as they have to be installed into a different prefix (e.g. /opt), so all 3rd party stuff won't work without user intervention (i.e. symlinks into /usr/...). Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: libtool rebuild required for updates-testing
On Sun, Aug 28, 2011 at 01:25:52PM +0200, Reindl Harald wrote: Hello Harald, currently updates-testing offers GVV 4.6.1 (thank you!) but libtool needs a rebuild for dependencies this time the rebuild runs on my testing-VM to rebuild all my packages later on this machine with new GCC, but this should also be in updates-testing Feedback like this is best given in the bodhi update: https://admin.fedoraproject.org/updates/gcc-4.6.1-8.fc15 as you can see gcc has already been unpushed because it has received three negative karma-points. The best way to get an issue like this to the package maintainers is to file a bug and then reference that bug in the bodhi feedback you give. There is already a bug on this issue in rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=734161 -- sven === jabber/xmpp: s...@lankes.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, 29 Aug 2011 10:27:40 -0500, JC (Jon) wrote: I'm not suggesting ddate is mission-critical, I just want reasons for it's removal or re-packaging to be well thought-out, not simply gosh, I don't sue that, so. . .. Otherwise we'll start dropping games. Sure (and not limited to games, which are in optional packages, however). We do that all the time, if a package maintainer no longer considers a game (or package in general) worthwhile, and if nobody else volunteers to take over a package. Of course, you're free to adapt as many orphans as you like, whether actively maintained upstream or ancient. Eventually, you'll be in the same situation, where you would like to drop something, be it a completely optional package or a plugin [*] you consider useless, close to useless, or just broken. [*] or a program with alternative user-interfaces Absolutely! I've been there. It's not the retirement of software I object to in this case, though I prefer to avoid that, it's the arbitrary deviation from upstream. If the deviation isn't arbitrary, I generally support it. All that aside, I'd be sad to see ddate go, but that's totally beside the point. :) -J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Padre-0.90.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Padre: c62fee6509129ad42ab4773a1f68b644 Padre-0.90.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On 08/29/2011 07:46 PM, Gregory Maxwell wrote: On Mon, Aug 29, 2011 at 9:55 AM, Rahul Sundaram wrote: Otherwise, make ddate a sub package and don't install it by default. Solved? As an upstream the willingness of distributions to strip out commands which I wanted to provide and don't offer a build option to disable via sub-packaging will simply encourage me to pack more functionality into single binaries that the distributions won't strip. That argument totally doesn't apply since the thread was started by the upstream maintainer. Besides, upstream cannot and should not try to control how packaging is done. Playing dirty tricks isn't the way to yield cooperation. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Mon, Aug 29, 2011 at 10:31:09AM -0500, Jon Ciesla wrote: P.S. Your argument will be moot when the kernel drops the floppy module. Is there actually a plan for this to happen? Curious, not arguing here. Not any time soon. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 08:32:01AM -0500, Jon Ciesla wrote: On Mon, 29 Aug 2011 15:42:18 +0300, KL (Kalev) wrote: On 08/29/2011 02:54 PM, Karel Zak wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? Please do. This isn't really something that should be dragged in for every single Fedora installation as part of the util-linux package. If someone actually misses the command, it can always be resurrected later in a subpackage. Someone? A single Discordian follower already, for example? Perhaps that person will volunteers as the maintainer of a separate package then? Or wait, if it's just one, why include it in the distribution? Based on http://en.wikipedia.org/wiki/Discordianism http://en.wikipedia.org/wiki/Discordianism#Discordian_calendar http://en.wikipedia.org/wiki/Church_of_the_SubGenius the ddate command and its manual's level of relationship to a religion (or a joke religion) enters a grey area with regard to the packaging policies: | Some examples of content which are not permissable: | | Comic book art files | Religious texts | ... https://fedoraproject.org/wiki/Packaging:Guidelines#Code_Vs_Content The Julian and Gregorian calendars are also of religious origin. OTOH including tiny programs that remind people that real religious belief is nonsense has to be a good thing. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [HEADS UP] remove ddate(1) command from rawhide
On Mon, Aug 29, 2011 at 6:54 AM, Karel Zak k...@redhat.com wrote: I'd like to remove: ddate - converts Gregorian dates to Discordian dates command from rawhide (F17). IMHO this crazy command is used by very very small minority of Fedora users. Comments? That would make me very sad. Instead please consider adding robotfindskitten to util-linux which would make me very happy. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2011-08-29)
=== #fedora-meeting: FESCO (2011-08-29) === Meeting started by sgallagh at 17:00:05 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-08-29/fesco.2011-08-29-17.00.log.html . Meeting summary --- * init process (sgallagh, 17:00:30) * #663 Late F16 Feature Java7 (sgallagh, 17:05:18) * AGREED: Remove Provides: java[*] from Java 7, require that all F16 official updates are built against Java 1.6 (sgallagh, 17:35:47) * ACTION: dbhole to update java-openjdk-1.7.0 to remove the Provides: (sgallagh, 17:39:03) * ACTION: dbhole to file Fedora 17 Feature Page for Java 7 (sgallagh, 17:40:39) * Next week's chair (sgallagh, 17:45:37) * Open Floor (sgallagh, 17:51:48) Meeting ended at 17:54:43 UTC. Action Items * dbhole to update java-openjdk-1.7.0 to remove the Provides: * dbhole to file Fedora 17 Feature Page for Java 7 Action Items, by person --- * dbhole * dbhole to update java-openjdk-1.7.0 to remove the Provides: * dbhole to file Fedora 17 Feature Page for Java 7 * **UNASSIGNED** * (none) People Present (lines said) --- * sgallagh (76) * dbhole (54) * nirik (48) * notting (8) * abadger1999 (5) * zodbot (5) * mjg59 (3) * gholms (1) * jsmith (1) * mmaslano (0) * init (0) * process (0) * t8m (0) * ajax (0) * pjones (0) * cwickert (0) * sgallagh#topic (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Mon, Aug 29, 2011 at 4:06 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Why don't we just get it running in koji? Once we can get a armv5tel/armv7hl running in koji we don't need to have people off doing their own thing and we can start moving forward as a group. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Mon, 2011-08-29 at 19:13 +0100, Peter Robinson wrote: On Mon, Aug 29, 2011 at 4:06 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Why don't we just get it running in koji? Once we can get a armv5tel/armv7hl running in koji we don't need to have people off doing their own thing and we can start moving forward as a group. We need a provisional set of repos to populate Koji. Arguably we might have enough now to get away with it, but we'd still wind up with lots of buildroot and false FTBFS type failures as Koji couldn't find deps. For better or worse, Dennis and I felt it was better to do a mock run first. The Koji build will happen soon. We need to do one more build to make sure we have every build dep in place during builds. Although we suspect we're good even with stage4, we'd like to make sure we don't have packages failing to enable features during build by doing it again in what we call stage5. Then, we're done. Lots of nice things could be done to improve this in the future, like bootstrap deps, etc. We'll keep an eye on builds this week. Some packages need huge resources to build, so they might be removed from the general list and built on a box we have that has a lot more RAM than many of the other builders. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [fedora-arm] Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Mon, Aug 29, 2011 at 7:22 PM, Jon Masters j...@redhat.com wrote: On Mon, 2011-08-29 at 19:13 +0100, Peter Robinson wrote: On Mon, Aug 29, 2011 at 4:06 AM, Jon Masters j...@redhat.com wrote: On Fri, 2011-08-26 at 09:51 -0400, Jon Masters wrote: To participate, visit the following link: http://scotland.proximity.on.ca/fedora-arm/f15hardfp/bootstrap/rootfs_stage4_20110825/ Just a quick update that we've had mock builders running around the clock and that, at last count we had built almost 9,000 native ARMv7 RPMs for the Fedora 15 bootstrap effort. I'll keep everyone updated. If you would like to contribute build cycles, please see my earlier mail, and ping us on #fedora-arm (irc.freenode.org) if you need assistance. Why don't we just get it running in koji? Once we can get a armv5tel/armv7hl running in koji we don't need to have people off doing their own thing and we can start moving forward as a group. We need a provisional set of repos to populate Koji. Arguably we might have enough now to get away with it, but we'd still wind up with lots of buildroot and false FTBFS type failures as Koji couldn't find deps. For better or worse, Dennis and I felt it was better to do a mock run first. The Koji build will happen soon. We need to do one more build to make sure we have every build dep in place during builds. Although we suspect we're good even with stage4, we'd like to make sure we don't have packages failing to enable features during build by doing it again in what we call stage5. Then, we're done. Lots of nice things could be done to improve this in the future, like bootstrap deps, etc. We'll keep an eye on builds this week. Some packages need huge resources to build, so they might be removed from the general list and built on a box we have that has a lot more RAM than many of the other builders. 2 points here. 1) If the dep is missing it needs to be built. that's the same whether its mock or koji. 2) need to do the same on armv5tel even if its for the core buildroot too. I don't see any movement on this. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Announce] Fedora Packager for Eclipse 0.2 released
Hi, We are happy to announce Fedora Packager for Eclipse (a.k.a. Eclipse Fedora Packager) 0.2. It comes with a lot of new features and many bug fixes. What's new? * Fedora RPM projects which should make packaging new software for Fedora a lot easier[1]. * SRPM based Koji scratch builds * SRPM import * Improved Mock builds * Keyboard short-cuts * Fedora Packaging perspective See our release notes for a more comprehensive list of bug-fixes and improvements[2]. Our updated user guide should help you to get started: https://fedoraproject.org/wiki/Fedora_Packager_For_Eclipse_User_Guide Where to get it? Either install Fedora Packager for Eclipse from our p2 repository[3] or get it directly from Koji[4]. Note that Fedora Packager for Eclipse 0.2 will be part of upcoming Fedora 16. In other words, you should be able to yum install it if you have a F16 machine available (yum install eclipse-fedorapackager). Fedora Packager for Eclipse works with Eclipse Indigo (3.7.0) and better. Found a bug, want a new feature? Please report/request them here: https://fedorahosted.org/eclipse-fedorapackager/newticket We'd love to hear your feedback! Many kudos to everyone involved making this our best release so far! Thanks, Severin [1] https://fedoraproject.org/wiki/Fedora_Packager_For_Eclipse_User_Guide#Creating_a_Local_Fedora_RPM_Project [2] https://fedorahosted.org/eclipse-fedorapackager/wiki/ReleaseNotes0.2.0 [3] https://fedorahosted.org/released/eclipse-fedorapackager/p2-repo/ [4] http://koji.fedoraproject.org/koji/taskinfo?taskID=3301545 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Mozilla-LDAP/f16] rebuild with latest f16 perl
commit ec1066b724d81d719af2f9008b506d55fbe7d9b2
Author: Rich Megginson rmegg...@redhat.com
Date: Mon Aug 29 12:55:34 2011 -0600
rebuild with latest f16 perl
perl-Mozilla-LDAP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Mozilla-LDAP.spec b/perl-Mozilla-LDAP.spec
index 61c139b..9218e75 100644
--- a/perl-Mozilla-LDAP.spec
+++ b/perl-Mozilla-LDAP.spec
@@ -1,7 +1,7 @@
Summary: LDAP Perl module that wraps the OpenLDAP C SDK
Name: perl-Mozilla-LDAP
Version: 1.5.3
-Release: 5%{?dist}
+Release: 6%{?dist}
License: GPLv2+ and LGPLv2+ and MPLv1.1
Group: Development/Libraries
URL: http://www.mozilla.org/directory/perldap.html
@@ -83,6 +83,9 @@ rm -rf $RPM_BUILD_ROOT
%doc CREDITS ChangeLog README MPL-1.1.txt
%changelog
+* Thu Aug 25 2011 Rich Megginson rmegg...@redhat.com - 1.5.3-6
+- rebuild with latest f16 perl
+
* Tue Feb 08 2011 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.5.3-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Fedora 15 ARM hardfp Virtual FAD (Fedora Activity Day) - TODAY
On Fri, Aug 26, 2011 at 11:41 AM, Niels de Vos de...@fedoraproject.org wrote: The builder I've enabled runs on the new OLPC within a chroot and that seems to work very well. I'm not sure if the kernel is a hfp one, but I don't think that was a requirement. Excellent! The kernels we provide atm are not hfp afaik -- but it shouldn't make any difference. I've found my XO-1.75s, attached to a USB HDD, to be an excellent build machine :-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
Brian C. Lane wrote: selinux is a big example of this, causing a large spike as it is installed. That should[1] no longer be an issue. [1] http://danwalsh.livejournal.com/45414.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements (was: Re: Fedora 16 Alpha i386 does not install in VMWare)
On Mon, Aug 29, 2011 at 9:55 PM, Brian C. Lane b...@redhat.com wrote: On Sat, Aug 27, 2011 at 04:15:37PM -0700, a...@clueserver.org wrote: In both cases I had 2 gigs of ram. Should not be a memory issue. That is more than enough. Please file a bug(s) and include the logs from /tmp/*log Memory usage during install also depends on what the packages being installed do in their pre/post scripts. selinux is a big example of this, causing a large spike as it is installed. SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, [1] 1: http://danwalsh.livejournal.com/45414.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Mon, Aug 29, 2011 at 1:00 PM, Michael Cronenworth m...@cchtml.com wrote: Brian C. Lane wrote: selinux is a big example of this, causing a large spike as it is installed. That should[1] no longer be an issue. [1] http://danwalsh.livejournal.com/45414.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I just repatched Anaconda to use 512M, it's slow for LiveMedia but it works fine. Not sure why it was bumped to 768M I haven;t had any issues yet, in virtual or physical environments. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On 2011/08/29 15:04 (GMT-0700) Jeremiah Summers composed: I just repatched Anaconda to use 512M Literally? If so, does that work on systems with 512M installed but with 8M allocated to an onboard video chip? -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] I18N and L10N Test Week
Hello all! Just a reminder that this week is internationalization and localization test week! This test week will focus on translations quality, keyboard support, langpack installation, fonts support and other aspects related to system behavior on different international environments. Please join us in #fedora-test-day at freenode and post your results on the wiki pages: https://fedoraproject.org/wiki/Test_Day:2011-08-30_L10n_Desktop https://fedoraproject.org/wiki/Test_Day:2011-08-31_L10n_I18n_Installation https://fedoraproject.org/wiki/Test_Day:2011-09-01_I18n_Desktop Regards, -- Igor Pires Soares Fedora Ambassador (Brazil) - Member of FAmSCo Fedora I18N/L10N QA https://fedoraproject.org/wiki/User:Igor ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Self Introduction
Hi all, My name is Steve Gordon, I'm a content author by day but I also have previous experience as a developer (primarily Java and...COBOL...). My current interests are primarily in virtualization and cloud software. I already have a FAS account through my membership of the documentation group but I'm introducing myself to the devel group because I want to package aqemu (http://sourceforge.net/projects/aqemu/) for Fedora! I have some prior experience packaging software for my own use/re-use but this is the first time I've submitted anything in the hope of ultimately getting formal inclusion into a distribution. For what it's worth my package review request is: https://bugzilla.redhat.com/show_bug.cgi?id=734275 Thanks all! Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Karel Zak wrote: On Mon, Aug 29, 2011 at 09:37:37AM -0500, Michael Cronenworth wrote: The kernel maintainers don't support the floppy module and the module hasn't been auto-loaded for several releases. Does it mean that modprobe floppy does not work? No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG. Similarily, analog joystick support (yes, those joysticks you plug on the MIDI ports of those old sound cards) also has to be modprobed manually. And yes, I have all that stuff plugged on this machine. I barely ever use it, but that doesn't mean I don't want it to work… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support (was: [HEADS UP] remove ddate(1) command from rawhide)
Once upon a time, Kevin Kofler kevin.kof...@chello.at said: No, it means that (unless this was recently fixed) you have to modprobe it manually (e.g. from rc.local) because nothing bothers trying to modprobe it for you anymore. IMHO, this is really broken, but the bug reports about it were ignored or declared NOTABUG. It is very irritating, since I only use floppies when I really need to, and usually I've upgraded the system (I typically do clean installs) since the last time. I always have to stop and manually configure the floppy drive again. For a while, USB floppy drives got correctly configured when you plugged them in (a udev rule was added to get /dev/floppy links and ownership), but that was removed somewhere along the line. I own the package for formatting floppies in USB drives (ufiformat), and it is also irritating when I go test it for new releases. With changes over time, I don't know how to get the device nodes with the correct access for the desktop user anymore, and I figure if somebody went to the trouble of removing the udev rules, there's not much point in asking to have them added back. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On 08/29/2011 10:22 PM, Chris Adams wrote: It is very irritating, since I only use floppies when I really need to, Is this due to the need to boot into DOS to run a firmware utility or something similar? If so, you can create a bootable, DOS USB flash drive. I haven't had a need for a floppy disk in years. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements (was: Re: Fedora 16 Alpha i386 does not install in VMWare)
On Mon, 2011-08-29 at 22:02 +0200, drago01 wrote: On Mon, Aug 29, 2011 at 9:55 PM, Brian C. Lane b...@redhat.com wrote: On Sat, Aug 27, 2011 at 04:15:37PM -0700, a...@clueserver.org wrote: In both cases I had 2 gigs of ram. Should not be a memory issue. That is more than enough. Please file a bug(s) and include the logs from /tmp/*log Memory usage during install also depends on what the packages being installed do in their pre/post scripts. selinux is a big example of this, causing a large spike as it is installed. SELinux Enhancements. SELinux policy package now includes a pre-built policy that will only rebuild policy if any customizations have been made. A sample test run shows 4 times speedup on installing the package from 48 Seconds to 12 Seconds and max memory usage from 38M to 6M. In addition to that, [1] 1: http://danwalsh.livejournal.com/45414.html Yes. The reason why that work has been done is because everyone kicked up a stink about anaconda using too much memory, so the anaconda team looked closer into what was taking up so much memory, found out selinux policy installation caused quite a significant chunk of it, and told Dan about it. None of this is news to anyone actually involved in the relevant development teams =) this topic has really been done to death on this list and many others. anaconda team is aware of the memory use issue and is working on fixing it. this selinux change is one of the fixes. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Memory requirements
On Mon, 2011-08-29 at 15:04 -0700, Jeremiah Summers wrote: On Mon, Aug 29, 2011 at 1:00 PM, Michael Cronenworth m...@cchtml.com wrote: Brian C. Lane wrote: selinux is a big example of this, causing a large spike as it is installed. That should[1] no longer be an issue. [1] http://danwalsh.livejournal.com/45414.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I just repatched Anaconda to use 512M, it's slow for LiveMedia but it works fine. Not sure why it was bumped to 768M I haven;t had any issues yet, in virtual or physical environments. live install is different from traditional install as it isn't installing any packages; no rpm scripts are run and take up resources. it's just dumping an image file to the hard disk. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: floppy support
On Tue, Aug 30, 2011 at 1:58 PM, Michael Cronenworth m...@cchtml.comwrote: On 08/29/2011 10:22 PM, Chris Adams wrote: It is very irritating, since I only use floppies when I really need to, Is this due to the need to boot into DOS to run a firmware utility or something similar? If so, you can create a bootable, DOS USB flash drive. I haven't had a need for a floppy disk in years. I can't see any reason for floppies these days considering their extreme price per data unit as opposed to usb memory. I don't flash much these days. And for times when I feel the need to, I go about it by whatever other means is necessary to avoid anything to do with floppies. That's not to say that the Linux kernel should not support floppy drives. That's an entirely different discussion really. Regards Chris Jones [image: linux.png] linux.png-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Makefile-DOM-0.006.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Makefile-DOM: c9136d35514d3445288d5f4b8cea5703 Makefile-DOM-0.006.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Makefile-DOM] 0.006 bump
commit b27e347b0b262ffa6fd59e521b961288bbd6eba4
Author: Petr Sabata con...@redhat.com
Date: Mon Aug 29 14:36:26 2011 +0200
0.006 bump
.gitignore |1 +
perl-Makefile-DOM.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 09e16f7..4798435 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Makefile-DOM-0.004.tar.gz
/Makefile-DOM-0.005.tar.gz
+/Makefile-DOM-0.006.tar.gz
diff --git a/perl-Makefile-DOM.spec b/perl-Makefile-DOM.spec
index e2b1f72..b9b0fd3 100644
--- a/perl-Makefile-DOM.spec
+++ b/perl-Makefile-DOM.spec
@@ -1,5 +1,5 @@
Name: perl-Makefile-DOM
-Version:0.005
+Version:0.006
Release:1%{?dist}
Summary:Simple DOM parser for Makefiles
License:GPL+ or Artistic
@@ -52,6 +52,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Aug 29 2011 Petr Sabata con...@redhat.com - 0.006-1
+- 0.006 bump
+
* Thu Aug 18 2011 Petr Sabata con...@redhat.com - 0.005-1
- 0.005 bump
- Removing now obsolete Buildroot and defattr
diff --git a/sources b/sources
index fabe25a..3c68ce5 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1c1ed7c3898b6b7e87cd2288d54fc30e Makefile-DOM-0.005.tar.gz
+c9136d35514d3445288d5f4b8cea5703 Makefile-DOM-0.006.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734052] perl-Makefile-DOM-0.006 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=734052 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Makefile-DOM-0.006-1.f ||c17 Resolution||RAWHIDE Last Closed||2011-08-29 08:37:51 -- 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-DateTime-Format-Epoch/f14] initial import (rhbz#730043)
Summary of changes: 283b2e9... initial import (rhbz#730043) (*) (*) This commit already existed in another branch; no separate mail sent -- 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 734253] New: HTML::Template 2.10 versioning problem
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: HTML::Template 2.10 versioning problem https://bugzilla.redhat.com/show_bug.cgi?id=734253 Summary: HTML::Template 2.10 versioning problem Product: Fedora Version: 16 Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: high Priority: unspecified Component: perl-HTML-Template AssignedTo: tcall...@redhat.com ReportedBy: ville.sky...@iki.fi QAContact: extras...@fedoraproject.org CC: tcall...@redhat.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- HTML::Template 2.10 is treated by perl's versioning comparisons as a floating point number, which means it's the same as if its version was 2.1. Upstream bug report: https://rt.cpan.org/Public/Bug/Display.html?id=70190 Reproducer: $ perl -e 'use HTML::Template 2.6' HTML::Template version 2.6 required--this is only version 2.10 at -e line 1. BEGIN failed--compilation aborted at -e line 1. rpm's version comparison is probably unaffected, but anything using e.g. use HTML::Template 2.x for x = 2 is now broken at runtime with HTML::Template 2.10. Packages included in Fedora broken such way include at least perl-HTML-Template-Expr and w3c-markup-validator. I'm not aware of an easy way to fix this in HTML::Template (apart from bumping the version to 3.00 but that's hardly something that should be done in the Fedora package), so I suppose affected packages could be patched so that any versions in their use HTML::Template statements are removed. Other ideas? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734271] New: Missing /etc/tmpfiles.d/amavisd.conf file
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: Missing /etc/tmpfiles.d/amavisd.conf file https://bugzilla.redhat.com/show_bug.cgi?id=734271 Summary: Missing /etc/tmpfiles.d/amavisd.conf file Product: Fedora Version: 15 Platform: x86_64 OS/Version: Linux Status: NEW Severity: high Priority: unspecified Component: amavisd-new AssignedTo: st...@silug.org ReportedBy: martin.marq...@gmail.com QAContact: extras...@fedoraproject.org CC: st...@silug.org, fedora-perl-devel-l...@redhat.com, kana...@kanarip.com Classification: Fedora Story Points: --- Type: --- Description of problem: Missing /etc/tmpfiles.d/amavisd.conf file. Version-Release number of selected component (if applicable): # rpm -q amavisd-new amavisd-new-2.6.4-3.fc15.noarch How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Amavis can't start because /var/run/amavisd/ doesn't exist Expected results: Additional info: -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 734271] Missing /etc/tmpfiles.d/amavisd.conf file
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=734271 --- Comment #1 from Martín Marqués martin.marq...@gmail.com 2011-08-29 20:21:34 EDT --- *** Bug 734272 has been marked as a duplicate of this bug. *** -- 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
