Re: Fan switch on permanently
On 03/24/12 at 01:42pm, Antonio Trande wrote: Hello. With my Acer Aspire 6930G happen that after an indefinite time, the fan starts to work permanently regardless of temperature. In this moment, according to nvclock [1] the GPU temp is 43°C and the fan is on; strangely because it starts to work over 47°C all along. If i format the BIOS, the fan goes back to work only over 47°C. Infos: [2] I don't know if this issue depends on Fedora, but i wish understand its cause. Had someone a similar experience o an idea of what is it ? Are you by any chance using nvidia binary drivers? I have a similarly sounding problem on my home laptop using nvidia 8400m and binary drivers. It's described here [1]. While it may not be exactly your problem, maybe it can provide some pointers/hints. [1] http://www.nvnews.net/vbulletin/showthread.php?s=9f6f6c4f2dcd351cecc8a7e890126229t=148976 Regards, -- Jan Synacek BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-03-26 @ 15:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2012-03-26 # Time: 15:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time once more. We have a beta to sign off on, so expect lots of happy fun blocker review. Also, I figured it'd be a good idea to kick around the 'QA as a sub-project' topic in a meeting. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20120326 The current proposed agenda is included below. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Fedora 17 Beta status / blocker review 3. 'Project' status 4. Test Day report 5. Upcoming QA events 6. AutoQA update 7. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django 1.4 in F17?
On 25/03/12 13:54, Jos Vos wrote: FWIW: Django 1.4 has now been officially released. I submitted an upgrade request in bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=806614 yes, thank you. We're aware of it. Please refer also to bug https://bugzilla.redhat.com/show_bug.cgi?id=806463 -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: memtest from F17 beta DVD images
- Original Message - I booted the F17 beta ISO (x86_64, if it matters) on two laptops and tried the provided memtest. In both cases it reported insane amounts of errors in test 7 after running successfully through tests 1..6. The reported error addresses are in the 120 MB area. I checked that when memtest is configured to go directly to test 7 the errors appear right away. I have not had the chance to retest with older images but the chance that both laptops independently developed RAM problems in the same area seems small. I'll do more tests and file a Bugzilla report if it checks out. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It seems to be related to gcc 4.7 update: https://bugzilla.redhat.com/show_bug.cgi?id=805813 Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Depcheck failed?
On Fri, Mar 23, 2012 at 1:25 PM, Jon Ciesla limburg...@gmail.com wrote: On Fri, Mar 23, 2012 at 1:23 PM, Richard Shaw hobbes1...@gmail.com wrote: Darn... I was hoping that wouldn't bite me :) I'm assuming I can ignore the error though? Or does it need to be fixed? Fix. :( Which means I really need to bump the release in rawhide, right? There's nothing I can do to the f17 package that would cause it to be the f18 package, unless killing the update is sufficient? Hey, have a look here: https://fedoraproject.org/wiki/AutoQA_tests/Upgradepath#Fixing_the_failures which links here: https://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bumps_for_old_branches This way you _can_ update just a single branch. Use '.fc17.1' suffix. Of course you must know whether you want to do this (whether the fix is really not needed in rawhide). And since pushing to rawhide is easy... your choice. PS: This test is called 'upgradepath', not 'depcheck'. See the headline in the results document. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Hi, they use a rather scary looking pile of development boards with very poor I/O. Buy a trimslice and run it with iSCSI. It's a very clean package, and I can get 80 MB/sec to my file server's disks. That is neither scary nor poor I/O. http://www.delorie.com/arm/trimslice/iscsi.html Running the thing on iscsi is a good idea, given that local storage is linked up via usb while gb ethernet is hooked up via pcie. Any particular reason why you boot the thing via tftp? I'd expect just having /boot on the sd card (which you need for boot anyway) is easier, especially when it comes to kernel updates. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann kra...@redhat.com wrote: Hi, they use a rather scary looking pile of development boards with very poor I/O. Buy a trimslice and run it with iSCSI. It's a very clean package, and I can get 80 MB/sec to my file server's disks. That is neither scary nor poor I/O. http://www.delorie.com/arm/trimslice/iscsi.html Running the thing on iscsi is a good idea, given that local storage is linked up via usb while gb ethernet is hooked up via pcie. Any particular reason why you boot the thing via tftp? I'd expect just having /boot on the sd card (which you need for boot anyway) is easier, especially when it comes to kernel updates. Everything needed to boot goes into the initrd now days so you don't even need the SD card. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Booting Fedora from LVM with grub2
On Sun, Mar 25, 2012 at 11:41:18PM +0200, Kevin Kofler wrote: Richard W.M. Jones wrote: Perhaps, like Ubuntu's installer, the graphical part of Anaconda should concentrate on doing the simple stuff, and leave everything else to kickstart non-graphical installations. I don't think that would be a good idea, at all. Umm ... okay. Any particular reason? Any other plans to make the current situation better? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
On Mon, Mar 26, 2012 at 12:57:44AM +0200, Oron Peled wrote: * IMO, it's important to have Debian packaging tools for Fedora so it can be used as a more complete development platform: - Currently, there's no problem building rpm's and yum repos on Debian as a development platform, but not the other way around - This means that a Debian/Ubuntu workstation can build both .deb and RPM packages, and we cannot use Fedora for a similar role. Is this really true? What happens if, say, your program depends on PCRE, which has different sonames on Debian/Ubuntu and Fedora (for essentially the same library): fedora$ rpm -qf /usr/lib64/libpcre.so.0 pcre-8.21-2.fc17.1.x86_64 ubuntu$ dpkg -S /lib/x86_64-linux-gnu/libpcre.so.3.12.1 libpcre3: /lib/x86_64-linux-gnu/libpcre.so.3.12.1 ubuntu$ dpkg -l libpcre3-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii libpcre3-dev 8.12-3ubuntu2 Perl 5 Compatible Regular Expression Library I don't understand how a binary built on one platform could be copied across to the other and work. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fan switch on permanently
2012/3/26 Jan Synacek jsyna...@redhat.com On 03/24/12 at 01:42pm, Antonio Trande wrote: Hello. With my Acer Aspire 6930G happen that after an indefinite time, the fan starts to work permanently regardless of temperature. In this moment, according to nvclock [1] the GPU temp is 43°C and the fan is on; strangely because it starts to work over 47°C all along. If i format the BIOS, the fan goes back to work only over 47°C. Infos: [2] I don't know if this issue depends on Fedora, but i wish understand its cause. Had someone a similar experience o an idea of what is it ? Are you by any chance using nvidia binary drivers? I have a similarly sounding problem on my home laptop using nvidia 8400m and binary drivers. It's described here [1]. While it may not be exactly your problem, maybe it can provide some pointers/hints. [1] http://www.nvnews.net/vbulletin/showthread.php?s=9f6f6c4f2dcd351cecc8a7e890126229t=148976 Regards, -- Jan Synacek BaseOS team Brno -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel No, i use only nouveau driver with Fedora (except Windows). -- *Antonio Trande Fedora Ambassador **mail*: mailto:sagit...@fedoraproject.org sagit...@fedoraproject.org *Homepage*: http://www.fedora-os.org *Sip Address* : sip:sagitter AT ekiga.net *Jabber http://jabber.org/* :sagitter AT jabber.org *GPG Key: 19E6DF27* -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On 03/24/2012 10:09 PM, Chris Murphy wrote: Fedora-17-Beta-x86_64-Live-Desktop.iso http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. The configuration tool firewall-config is the main configuration tool for the firewall daemon. But I'm not finding firewall-config. So unlike with iptables, where I had a GUI Firewall app, now I no longer have an easy or obvious way of altering the default behavior and I'm in effect stuck without ssh. Seems the missing firewall-config is probably an oversight, and it needs to be included on LiveCD installs, and default DVD installs as well. Chris Murphy firewalld-config is not finished, yet. I am working on it. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F17, firewalld, avahi
On 03/24/2012 10:09 PM, Chris Murphy wrote: Fedora-17-Beta-x86_64-Live-Desktop.iso http://fedoraproject.org/wiki/FirewallD suggests I should have firewall-config. The configuration tool firewall-config is the main configuration tool for the firewall daemon. But I'm not finding firewall-config. So unlike with iptables, where I had a GUI Firewall app, now I no longer have an easy or obvious way of altering the default behavior and I'm in effect stuck without ssh. Seems the missing firewall-config is probably an oversight, and it needs to be included on LiveCD installs, and default DVD installs as well. Chris Murphy Please use firewall-cmd for now. Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On 03/26/12 11:00, Peter Robinson wrote: On Mon, Mar 26, 2012 at 9:41 AM, Gerd Hoffmann kra...@redhat.com wrote: Hi, they use a rather scary looking pile of development boards with very poor I/O. Buy a trimslice and run it with iSCSI. It's a very clean package, and I can get 80 MB/sec to my file server's disks. That is neither scary nor poor I/O. http://www.delorie.com/arm/trimslice/iscsi.html Running the thing on iscsi is a good idea, given that local storage is linked up via usb while gb ethernet is hooked up via pcie. Any particular reason why you boot the thing via tftp? I'd expect just having /boot on the sd card (which you need for boot anyway) is easier, especially when it comes to kernel updates. Everything needed to boot goes into the initrd now days so you don't even need the SD card. Check the URL above. The setup described there uses a sdcard with a u-boot script, which kicks off the tftp boot. I don't see the point in using tftp, you can place kernel+initrd directly at the sdcard if you have one anyway. Another possible way would be to boot directly from iscsi like you can do on x86 with an sanboot-enabled iPXE rom. I have no idea whenever u-boot can handle that though. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases
On 03/26/2012 01:57 AM, Oron Peled wrote: On Sunday, 25 בMarch 2012 20:01:37 Kalev Lember wrote: For the past 17 months, each rawhide report has had broken dh-make deps. The package was imported 21 Oct 2010 depending on a non-existing debhelper package and has been broken ever since. Regretfully, you are correct. What's not so clear is how can we *fix* this instead of abolishing all this package chain: Wonderful. Fixing the package sounds much better than just removing it. [snip] * As I mentioned on some of these bug-reports, I'm willing to maintain all these packages (see below). However, I wasn't the one submitting the BR, nor the reviewer. What process should I follow to make this happen? Have you tried emailing Jeroen to see if he can let you take over dh-make / approve you as a co-maintainer? If he's not replying, I guess you could try the https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers Regarding unfinished package review tickets, just open new ones under your own name and close the old ones as a duplicate, as per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews . Then you can continue working on importing the rest of the deps. Good luck with this! -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Managing the GNOME updates in Fedora
At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind. For the GNOME 3.4.0 release, I'm asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I'm intending to do the 3.4.1 update as one update as well. So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don't file an update. Instead add the build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc and then I'll pick up the build for the mega update. Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it' just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot. Thanks, Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
On Mon, Mar 26, 2012 at 11:52 AM, Richard Hughes hughsi...@gmail.com wrote: At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind. For the GNOME 3.4.0 release, I'm asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I'm intending to do the 3.4.1 update as one update as well. So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don't file an update. Instead add the build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc and then I'll pick up the build for the mega update. Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it' just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot. It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed
Took a bit longer to get there (some initial issues with the alpha needed fixing first), but rpm 4.9.90 has been in the rawhide buildroots now for a few hours with no apparent issues. Knock wood. As a reminder, at least the following packages will now need a rebuild due to the soname bump: Owner Package abrt-team abrt abrt-team libreport anaconda-maint anaconda ensclibextractor fchesystemtap ivaxer opensips jancratochvil gdb jcollie asterisk jdieter deltarpm jsafranenet-snmp kklic libsolv lkundrakovaldi mlichvarrpmreaper mmaslanoperl-RPM2 mprivoznlibvirt-snmp peter openser ppisar perl-RPM-VersionCompare pvrabec openscap pvrabec sectool rhughes PackageKit rhughes zif rmeggins389-ds-base rohara foghorn sharkcz openhpi-subagent - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed
On Mon, 2012-03-26 at 14:24 +0300, Panu Matilainen wrote: As a reminder, at least the following packages will now need a rebuild due to the soname bump: jdieter deltarpm Did I see that you took care of this one for me? Jonathan signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Language-Prolog-Yaswi
perl-Language-Prolog-Yaswi has broken dependencies in the F-17 tree: On x86_64: perl-Language-Prolog-Yaswi-0.19-1.fc17.x86_64 requires libswipl.so.5.10.5()(64bit) On i386: perl-Language-Prolog-Yaswi-0.19-1.fc17.i686 requires libswipl.so.5.10.5 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 String-ToIdentifier-EN-0.07.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-String-ToIdentifier-EN: fb99f7b8bb574bf650563e6e1fd198a2 String-ToIdentifier-EN-0.07.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-String-ToIdentifier-EN] update to 0.07
commit 24b6cb7d7cb3b49419abb559038e59c07f5d0f32
Author: Iain Arnell iarn...@gmail.com
Date: Mon Mar 26 05:34:48 2012 -0600
update to 0.07
.gitignore |1 +
perl-String-ToIdentifier-EN.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index a6ccaef..1a7da9c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/String-ToIdentifier-EN-0.06.tar.gz
+/String-ToIdentifier-EN-0.07.tar.gz
diff --git a/perl-String-ToIdentifier-EN.spec b/perl-String-ToIdentifier-EN.spec
index 64e7ff8..cf51cb7 100644
--- a/perl-String-ToIdentifier-EN.spec
+++ b/perl-String-ToIdentifier-EN.spec
@@ -1,5 +1,5 @@
Name: perl-String-ToIdentifier-EN
-Version:0.06
+Version:0.07
Release:1%{?dist}
Summary:Convert Strings to English Program Identifiers
License:GPL+ or Artistic
@@ -48,5 +48,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 26 2012 Iain Arnell iarn...@gmail.com 0.07-1
+- update to latest upstream version
+
* Fri Jan 13 2012 Iain Arnell iarn...@gmail.com 0.06-1
- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index 4968e66..41df8c1 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-262602c5b29b3a62fbf8ebc005bfebee String-ToIdentifier-EN-0.06.tar.gz
+fb99f7b8bb574bf650563e6e1fd198a2 String-ToIdentifier-EN-0.07.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
Plan for tomorrow's FESCo meeting (2012-03-26 at 17UTC)
Following is the list of topics that will be discussed in the FESCo meeting today at 17:00UTC (1:00pm EST, 19:00 CEST) in #fedora-meeting on irc.freenode.net. Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #699 Proposal to remove the package tzdata from Critical Path .fesco 699 #830 F18 Feature: ARM as Primary Arch -- https://fedoraproject.org/wiki/Features/FedoraARM .fesco 830 = New business = #829 New sponsor request: Pavel Alexeev (hubbitus) .fesco 829 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-RPM-VersionCompare] Rebuild against RPM 4.10
commit b16cf593384c95133c8c0383c6be9bcc42524a70
Author: Petr Písař ppi...@redhat.com
Date: Mon Mar 26 13:36:03 2012 +0200
Rebuild against RPM 4.10
perl-RPM-VersionCompare.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-RPM-VersionCompare.spec b/perl-RPM-VersionCompare.spec
index e0b7dff..db02674 100644
--- a/perl-RPM-VersionCompare.spec
+++ b/perl-RPM-VersionCompare.spec
@@ -1,6 +1,6 @@
Name: perl-RPM-VersionCompare
Version:0.1.1
-Release:2%{?dist}
+Release:3%{?dist}
Summary:Compare RPM version strings
License:GPLv3+
Group: Development/Libraries
@@ -50,6 +50,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 26 2012 Petr Pisar ppi...@redhat.com - 0.1.1-3
+- Rebuild against RPM 4.10
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.1.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F-17 Branched report: 20120326 changes
Compose started at Mon Mar 26 08:15:04 UTC 2012 Broken deps for x86_64 -- [HippoDraw] HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri [alexandria] alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8 [catfish] catfish-engines-0.3.2-4.fc17.1.noarch requires pinot [comoonics-cdsl-py] comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py [comoonics-cluster-py] comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py [contextkit] contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) [converseen] converseen-0.4.9-3.fc17.x86_64 requires libMagickWand.so.5()(64bit) converseen-0.4.9-3.fc17.x86_64 requires libMagickCore.so.5()(64bit) converseen-0.4.9-3.fc17.x86_64 requires libMagick++.so.5()(64bit) [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [eruby] eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8 eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gearmand] gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit) gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit) gearmand-0.23-2.fc17.x86_64 requires libboost_program_options-mt.so.1.47.0()(64bit) [genius] genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit) [gnome-phone-manager] gnome-phone-manager-0.66-9.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gnome-user-share] gnome-user-share-3.0.1-3.fc17.x86_64 requires libgnome-bluetooth.so.9()(64bit) [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [gscribble] gscribble-0.1.2-2.fc17.noarch requires gnome-python2-gtkhtml2 [i3] i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit) i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit) [ibus-fep] ibus-fep-1.4.3-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-gucharmap] ibus-gucharmap-1.4.0-3.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-panel-extensions] ibus-panel-extensions-1.4.99.20111207-1.fc17.i686 requires libibus-1.0.so.0 ibus-panel-extensions-1.4.99.20111207-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [ibus-unikey] ibus-unikey-0.6.1-1.fc17.x86_64 requires libibus-1.0.so.0()(64bit) [jboss-jaxrpc-1.1-api] jboss-jaxrpc-1.1-api-1.0.1-0.1.20120309gita3c227.fc17.noarch requires jboss-servlet-3.0-api [kazehakase] kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires ruby(abi) = 0:1.8 kazehakase-ruby-0.5.8-11.svn3873_trunk.fc17.x86_64 requires libruby.so.1.8()(64bit) [libprelude] 1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires ruby(abi) = 0:1.8 1:libprelude-ruby-1.0.0-11.fc17.x86_64 requires libruby.so.1.8()(64bit) [libteam] libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-route-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-nf-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-genl-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-cli-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.i686 requires libnl-3.so.199 libteam-0.1-3.20120130gitb5cf2a8.fc17.x86_64
Re: rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed
On 03/26/2012 02:30 PM, Jonathan Dieter wrote: On Mon, 2012-03-26 at 14:24 +0300, Panu Matilainen wrote: As a reminder, at least the following packages will now need a rebuild due to the soname bump: jdieter deltarpm Did I see that you took care of this one for me? Doh... Sorry I forgot to remove that from the list. Deltarpm has indeed been already rebuilt. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
On 26 March 2012 11:58, Peter Robinson pbrobin...@gmail.com wrote: It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix. Yes, this is a valid critisism. I'm hoping to write a tool to automatically update GNOME builds in a stable release and in rawhide (that watches ftp-release list), rather than having to do it all manually. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Mon, Mar 26, 2012 at 12:26:47PM +0200, Gerd Hoffmann wrote: Another possible way would be to boot directly from iscsi like you can do on x86 with an sanboot-enabled iPXE rom. I have no idea whenever u-boot can handle that though. No. The U-boot supplied on the Trim-Slice is very simplistic in the way it boots: It looks for a compiled script called boot.scr in four possible local storage locations. The script can then boot over the network, but you've got to have the script in a local location in the first place. http://www.trimslice.com/wiki/index.php/Trim-Slice_U-Boot [You could also patch U-boot. It's apparently stored in some on-motherboard serial flash memory.] Which leads me to a rant about ARM. G RANT!! I didn't think I'd ever love the BIOS, but compared to the alternatives (UEFI and a million different ARM bootloaders) it's simple and effective. 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: rpm 4.10 alpha now in rawhide, rebuilds for soname bump needed
On Mon, 2012-03-26 at 14:48 +0300, Panu Matilainen wrote: On 03/26/2012 02:30 PM, Jonathan Dieter wrote: On Mon, 2012-03-26 at 14:24 +0300, Panu Matilainen wrote: As a reminder, at least the following packages will now need a rebuild due to the soname bump: jdieter deltarpm Did I see that you took care of this one for me? Doh... Sorry I forgot to remove that from the list. Deltarpm has indeed been already rebuilt. Thanks much! Jonathan 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: Error: buildroot override already exists
On Sat, Mar 24, 2012 at 2:14 PM, Ricardo Argüello rica...@fedoraproject.org wrote: On Sat, Mar 24, 2012 at 11:18 AM, Jerry James loganje...@gmail.com wrote: On Sat, Mar 24, 2012 at 9:46 AM, Ricardo Argüello rica...@fedoraproject.org wrote: Hi, I need to do a buildroot override for jboss-connector-1.6-api-1.0.1-0.1.20120310git9dc9a5.fc17, in order to compile picketbox-4.0.6-5 in F17: http://koji.fedoraproject.org/koji/taskinfo?taskID=3929166 But when I try to create that buildroot override, Bodhi gives me this error: Error: buildroot override for u'jboss-connector-1.6-api-1.0.1-0.1.20120310git9dc9a5.fc17' already exists The only override I have now is for 'infinispan'. Any ideas? I had this happen once, too. Select the Show expired overrides link on the upper right, and find the override for jboss-connector. I think packages are counted as expired overrides once they get pushed to testing, or something like that. I think the user interface leaves a lot to be desired, as this is not intuitive behavior for us packagers. Thanks for the tip. I updated the Expiration Date for the old override and I'm waiting to see if it works. Thanks, it worked -- Ricardo Argüello rica...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 806884] New: RPM2 can't be built with new rpm-4.10
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: RPM2 can't be built with new rpm-4.10 https://bugzilla.redhat.com/show_bug.cgi?id=806884 Summary: RPM2 can't be built with new rpm-4.10 Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Severity: unspecified Priority: unspecified Component: perl-RPM2 AssignedTo: mmasl...@redhat.com ReportedBy: mmasl...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, lkund...@v3.sk, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- gcc -I/usr/lib64/perl5/CORE -DXS_VERSION=1.0 -DVERSION=1.0 -fPIC -DRPM2_API=4009 -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -o lib/RPM2.o lib/RPM2.c lib/RPM2.xs: In function '_null_callback': lib/RPM2.xs:74:3: error: 'rpmcliHashesCurrent' undeclared (first use in this function) lib/RPM2.xs:74:3: note: each undeclared identifier is reported only once for each function it appears in lib/RPM2.xs:85:3: error: 'rpmcliProgressTotal' undeclared (first use in this function) lib/RPM2.xs:86:3: error: 'rpmcliProgressCurrent' undeclared (first use in this function) lib/RPM2.xs:90:25: error: 'rpmcliPackagesTotal' undeclared (first use in this function) lib/RPM2.xs:36:6: warning: variable 'xx' set but not used [-Wunused-but-set-variable] lib/RPM2.c: In function 'XS_RPM2__C__PackageIterator__iterator_next': lib/RPM2.c:621:9: warning: variable 'RETVAL' set but not used [-Wunused-but-set-variable] error building lib/RPM2.o from 'lib/RPM2.c' at /usr/share/perl5/ExtUtils/CBuilder/Base.pm line 175. error: Bad exit status from /var/tmp/rpm-tmp.okPYIr (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.okPYIr (%build) -- 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
F16: Kernel bug with USB disks ?
Hi, I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having problems with a MicroSD card connected to a USB card reader. This has been working fine until recently (at least in F14 on the same hardware). The problem is that umount does not appear to be working correctly. I have an ext3 file system on the card. I can mount it, and I can copy files to it. However when I use the umount ... command it returns instantly (should sync the files to the card). The system says the card is unmounted (at least it is not listed with mount, df etc). However if I run sync, there is a lot of disk activity to the card ... Also if I try and run mkfs it says the device in in use ... If I mount a blank card it lists the files present on the previous card ... This sounds like a nasty kernel bug ... Anyone else seen this ? Cheers Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: Kernel bug with USB disks ?
On 03/26/2012 02:05 PM, Terry Barnaby wrote: Hi, I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having problems with a MicroSD card connected to a USB card reader. This has been working fine until recently (at least in F14 on the same hardware). The problem is that umount does not appear to be working correctly. I have an ext3 file system on the card. I can mount it, and I can copy files to it. However when I use the umount ... command it returns instantly (should sync the files to the card). The system says the card is unmounted (at least it is not listed with mount, df etc). However if I run sync, there is a lot of disk activity to the card ... Also if I try and run mkfs it says the device in in use ... If I mount a blank card it lists the files present on the previous card ... This sounds like a nasty kernel bug ... Anyone else seen this ? Cheers Terry Looks like kernel 3.2.9-2.fc16.i686.PAE is ok ... Cheers Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: Kernel bug with USB disks ?
I filled a bugreport moths ago, but actually I cannot get the id number, maybe later I can try again Il giorno 26/mar/2012 15:05, Terry Barnaby ter...@beam.ltd.uk ha scritto: Hi, I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having problems with a MicroSD card connected to a USB card reader. This has been working fine until recently (at least in F14 on the same hardware). The problem is that umount does not appear to be working correctly. I have an ext3 file system on the card. I can mount it, and I can copy files to it. However when I use the umount ... command it returns instantly (should sync the files to the card). The system says the card is unmounted (at least it is not listed with mount, df etc). However if I run sync, there is a lot of disk activity to the card ... Also if I try and run mkfs it says the device in in use ... If I mount a blank card it lists the files present on the previous card ... This sounds like a nasty kernel bug ... Anyone else seen this ? Cheers Terry -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Tie-RefHash-Weak/f17] Spec clean-up
Summary of changes: 9c97ff7... Spec clean-up (*) (*) 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
Fedora 17 Beta Go/No-Go Meeting, Wednesday, March 28, @17:00 Eastern
Please join us on irc.freenode.net in #fedora-meeting-1 for this important meeting. Will the Beefy Miracle live up to the latter half of its name? Attend this meeting and find out! :) Wednesday, March 28, 2012 @21:00 UTC (17:00 EDT/14:00 PDT) Before each public release Development, QA and Release Engineering meet to determine if the release criteria are met for a particular release. This meeting is called the Go/No-Go Meeting. Verifying that the Release criteria are met is the responsibility of the QA Team. For more details about this meeting see: https://fedoraproject.org/wiki/Go_No_Go_Meeting In the meantime, keep an eye on the Fedora 17 Beta Blocker list: http://fedoraproject.org/wiki/Current_Release_Blockers Ongoing Beta RC test results can be seen here: https://fedoraproject.org/wiki/Category:Fedora_17_Beta_RC_Test_Results Cheers! (And do note that we will be in #fedora-meeting-1!) -Robyn ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
Richard Hughes wrote: At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind. the kde-sig has similar pain-points doing mass updates. Having a list of pkgs to build (seems done on google docs in your case already, good), and having your own koji tag/target does seem to simplify matters a bunch. Then it's relatively easy to compose a bodhi update from the output from: koji list-tagged --latest f16-gnome for example. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
On Mon, 2012-03-26 at 11:58 +0100, Peter Robinson wrote: . It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix. The trick is to not build for rawhide ever, until after the stable release is out, and instead rely on inheritance. Since building everything twice is just a terrible waste of effort, and makes this whole mass building thing even more of a torture. But, of course, this only works if you get on the right track when doing the first build after the fork - unfortunately, our forking setup makes it not easy to avoid doing at least one accidental F18 build before you notice the new branch... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
gforth and gcc 4.7
Trying to build gforth with gcc 4.7 fails currently. The forth engine is build but it fails its included tests. The problem is that every newline the forth engine writes is replaced with 0x00 as seen in following diff: 010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU 020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S 030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC -040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !# ^^ actual output +040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !# ^^ expected output 050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%'()*+,-./0123 Removing -O2 from the compiler commandline fixes it, but I have no idea why this happens. Does anyone have an idea how this can be solved? Adrian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 806922] perl-Socket-2.000-2 does not build in ARM Koji
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=806922 --- Comment #2 from Petr Pisar ppi...@redhat.com 2012-03-26 10:39:01 EDT --- Upgrading gcc and rpm-build did not help. Running tests verbosely shows last 4 test are missing: [...] ok 24 - pack_sockaddr_in6-unpack_sockaddr_in6 scope_id ok 25 - pack_sockaddr_in6-unpack_sockaddr_in6 flowinfo ok 26 - sockaddr_in6 in list context unpacks ok 27 - sockaddr_in6 in scalar context packs ok 28 - sockaddr_un can handle abstract AF_UNIX paths ok 29 - sockaddr_un abstract address length ok 30 - sockaddr_in deprecated form doesn't warn without lexical warnings ok 31 - sockaddr_in deprecated form warns with lexical warnings -- 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
Intent to retire: mod_python
mod_python upstream has been inactive for five years, since Graham Dumpleton went to work on mod_wsgi. IMO it is long past time to retire mod_python in Fedora. But the following packages still depend on it: Source : glump-0.9.11-10.fc17.src.rpm Source : koji-1.6.0-3.fc17.src.rpm Source : viewvc-1.1.13-1.fc17.src.rpm Source : yawn-0-0.3.20120227svn561.fc18.src.rpm I haven't checked whether these are simply to convert over to WSGI or not. Does anybody want to maintain mod_python? If not, I'm going to retire it. Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Intent to retire: mod_python
Le lundi 26 mars 2012 à 16:04 +0100, Joe Orton a écrit : mod_python upstream has been inactive for five years, since Graham Dumpleton went to work on mod_wsgi. IMO it is long past time to retire mod_python in Fedora. But the following packages still depend on it: Source : glump-0.9.11-10.fc17.src.rpm Source : koji-1.6.0-3.fc17.src.rpm Source : viewvc-1.1.13-1.fc17.src.rpm it support wsgi since a few versions ( using it in production ), but due to various issues, consume lots of memory :/ Source : yawn-0-0.3.20120227svn561.fc18.src.rpm I haven't checked whether these are simply to convert over to WSGI or not. Does anybody want to maintain mod_python? If not, I'm going to retire it. Regards, Joe -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F16: last superblock write time in future
i notice this since upgraded to Fedora 16 on mostly all virtual machines while i have never seeen this with F15 how to track down and for which component file a bugreport? EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[606]: /tmp: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[606]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[609]: /var/cache: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[609]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[611]: /Volumes/dune: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[611]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[607]: /var/log: 85/65280 Dateien (24.7% nicht zusammenh\xffc3\xffa4\xffa4ngend), 15985/261048 Bl\xffc3\xffb6\xffb6cke signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald h.rei...@thelounge.net wrote: i notice this since upgraded to Fedora 16 on mostly all virtual machines while i have never seeen this with F15 how to track down and for which component file a bugreport? http://forums.fedoraforum.org/showthread.php?t=273727 -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
On Mon, Mar 26, 2012 at 9:29 AM, Jef Spaleta jspal...@gmail.com wrote: On Mon, Mar 26, 2012 at 8:16 AM, Reindl Harald h.rei...@thelounge.net wrote: i notice this since upgraded to Fedora 16 on mostly all virtual machines while i have never seeen this with F15 how to track down and for which component file a bugreport? http://forums.fedoraforum.org/showthread.php?t=273727 Bug report from 2009 concerning the very same issue. https://bugzilla.redhat.com/show_bug.cgi?id=522969 You'll note that this is clearly a cyclic issue that comes and goes across multiple release timescales...as far back as F9. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
On Mon, Mar 26, 2012 at 6:16 PM, Reindl Harald h.rei...@thelounge.net wrote: i notice this since upgraded to Fedora 16 on mostly all virtual machines while i have never seeen this with F15 how to track down and for which component file a bugreport? EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. Compare the hardware clock and system time, you might be hitting something like https://bugzilla.redhat.com/show_bug.cgi?id=750883 . Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Any particular reason why you boot the thing via tftp? I'd expect just having /boot on the sd card (which you need for boot anyway) is easier, especially when it comes to kernel updates. I wanted the minimum on the sdcard (it just has the tftboot script) because our build farm only has one local person, and he's not always there. With everything on the server, we can swap everything out, power cycle it, and be done. Remember, the iscsi volumes can be mounted on your regular desktop if needed, to fix the image before booting the trimslice. Plus, my way can use ancient tiny sdcards without worrying about space or performance. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
On 3/26/12 11:16 AM, Reindl Harald wrote: i notice this since upgraded to Fedora 16 on mostly all virtual machines while i have never seeen this with F15 how to track down and for which component file a bugreport? EXT4-fs (sda1): mounted filesystem without journal. Opts: noacl,nouser_xattr systemd-fsck[607]: /var/log: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[607]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[606]: /tmp: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[606]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[609]: /var/cache: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[609]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[611]: /Volumes/dune: Der Zeitpunkt des letzten Schreibens von SuperBlock liegt in der Zukunft. systemd-fsck[611]: (weniger als ein Tag, wahrscheinlich aufgrund falsch gesetzter Hardware-Uhr) REPARIERT. systemd-fsck[607]: /var/log: 85/65280 Dateien (24.7% nicht zusammenh\xffc3\xffa4\xffa4ngend), 15985/261048 Bl\xffc3\xffb6\xffb6cke N_(@S last write time is in the future.\n\t(by less than a day, probably due to the hardware clock being incorrectly set). ), These messages are from e2fsck... Can you check whether the hardware clock is being moved back when you reboot? -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gforth and gcc 4.7
On Mon, Mar 26, 2012 at 04:54:05PM +0200, Adrian Reber wrote: Trying to build gforth with gcc 4.7 fails currently. The forth engine is build but it fails its included tests. The problem is that every newline the forth engine writes is replaced with 0x00 as seen in following diff: 010: 6566 696e 6564 2047 4458 2020 594f 5520 efined GDX YOU 020: 5348 4f55 4c44 2053 4545 2054 4845 2053 SHOULD SEE THE S 030: 5441 4e44 4152 4420 4752 4150 4849 4320 TANDARD GRAPHIC -040: 4348 4152 4143 5445 5253 3a00 2021 2223 CHARACTERS:. !# ^^ actual output +040: 4348 4152 4143 5445 5253 3a0a 2021 2223 CHARACTERS:. !# ^^ expected output 050: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%'()*+,-./0123 Removing -O2 from the compiler commandline fixes it, but I have no idea why this happens. Does anyone have an idea how this can be solved? If -O0 works and -O2 doesn't, first narrow it down using a binary search between -O0 and -O2 compiled objects to at least a single compilation unit, then you could use __attribute__((optimize (0))) (resp. __attribute__((optimize (2))) ) and/or -fno-inline to narrow it even further, read the problematic code, see if there aren't any e.g. aliasing warnings (-O2 enables -fstrict-aliasing), if you don't spot a bug in the gforth code after this and still suspect the compiler, turn that into self-contained minimal testcase (for the problematic routine add main that calls it with the right arguments, make the problematic routine __attribute__((noinline, noclone)) and stub out anything it calls, then file a gcc bugreport? Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Which leads me to a rant about ARM. G RANT!! I didn't think I'd ever love the BIOS, but compared to the alternatives (UEFI and a million different ARM bootloaders) it's simple and effective. This is getting way off-topic, but... most linux-capable ARM chips support a BIOS in the pc sense. Vendors choose not to do it that way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
Am 26.03.2012 20:22, schrieb Jef Spaleta: hmmm - which HWCLOCK clock? we are speaking about VMware Machines on ESXi/vSphere My best suggestion for you is to read the following document. www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf and follow the best practises outlined there. You should have your linux guests setting so system time is in UTC not local time. I would suspect base on your symptoms you've got the wrong settings for the guest operating system. The issue here is long standing and predates systemd. You really do need to follow the best practise recommendations set forth by vmware when using their virtualization product. the document above is hughe outdated this machines are installed 2008 with F9 and since then upgraded, the first time this ever happens is after upgrade to F16 all guests are using two ntp-servers in the LAN and time is stable as long no reboot is done proven by the following output which is a script calling date per ssh on each guest Mo 26. Mär 20:40:41 CEST 2012 Mo 26. Mär 20:40:41 CEST 2012 Mo 26. Mär 20:40:41 CEST 2012 Mo 26. Mär 20:40:42 CEST 2012 Mo 26. Mär 20:40:42 CEST 2012 Mo 26. Mär 20:40:42 CEST 2012 Mo 26. Mär 20:40:43 CEST 2012 Mo 26. Mär 20:40:43 CEST 2012 Mo 26. Mär 20:40:43 CEST 2012 Mo 26. Mär 20:40:44 CEST 2012 Mo 26. Mär 20:40:44 CEST 2012 Mo 26. Mär 20:40:44 CEST 2012 Mo 26. Mär 20:40:45 CEST 2012 Mo 26. Mär 20:40:45 CEST 2012 Mo 26. Mär 20:40:46 CEST 2012 Mo 26. Mär 20:40:46 CEST 2012 Mo 26. Mär 20:40:47 CEST 2012 Mo 26. Mär 20:40:47 CEST 2012 Mo 26. Mär 20:40:47 CEST 2012 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
On Mon, Mar 26, 2012 at 10:42 AM, Reindl Harald h.rei...@thelounge.net wrote: the document above is hughe outdated Oh well. Nevermind then. Good luck correcting your configs -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-App-Cmd] Update to 0.317
commit d7f775a901ed75c709cc7cc4ff0a7693ba987ffa
Author: Emmanuel Seyman emmanuel.sey...@club-internet.fr
Date: Mon Mar 26 21:14:49 2012 +0200
Update to 0.317
.gitignore|1 +
perl-App-Cmd.spec |6 +-
sources |2 +-
3 files changed, 7 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 7eb7690..8aa1cf6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ App-Cmd-0.307.tar.gz
/App-Cmd-0.314.tar.gz
/App-Cmd-0.315.tar.gz
/App-Cmd-0.316.tar.gz
+/App-Cmd-0.317.tar.gz
diff --git a/perl-App-Cmd.spec b/perl-App-Cmd.spec
index afc8f00..b42dc5d 100644
--- a/perl-App-Cmd.spec
+++ b/perl-App-Cmd.spec
@@ -1,6 +1,6 @@
Name: perl-App-Cmd
Summary:Write command line apps with less suffering
-Version:0.316
+Version:0.317
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -9,6 +9,7 @@ URL:http://search.cpan.org/dist/App-Cmd
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
+BuildRequires: perl(parent)
BuildRequires: perl(Capture::Tiny)
BuildRequires: perl(Carp)
BuildRequires: perl(Class::Load) = 0.06
@@ -72,6 +73,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Mon Mar 26 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.317-1
+- Update to 0.317
+
* Sun Feb 12 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.316-1
- Update to 0.316
diff --git a/sources b/sources
index 1721aaa..e115d6c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-441facfdfbcf62541247bb6da4df6396 App-Cmd-0.316.tar.gz
+0c0bcc097c1530a8059469ff3e7524d1 App-Cmd-0.317.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: httpd 2.4 is coming, RFC on module packaging draft
On Fri, Mar 23, 2012 at 06:39:25PM +0100, Michał Piotrowski wrote: Do you know if the new version of httpd has major changes in modules API? I'm trying to cobble together spec file for mod_spdy https://github.com/eventhorizonpl/mod_spdy/blob/master/mod_spdy.spec and I hope to finish it for F18 :) Hi Michal, yes, there are changes in the 2.4 module API, though mostly relatively small - details are here: http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html Regards, Joe -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
Am 26.03.2012 21:11, schrieb Jef Spaleta: On Mon, Mar 26, 2012 at 10:42 AM, Reindl Harald h.rei...@thelounge.net wrote: the document above is hughe outdated Oh well. Nevermind then. Good luck correcting your configs as you see in this output the configs are correct this 19 guests are using the same ntp-servers (ntpd not chrony) a script on one machine fires up date on each one 3 of them are currently F15, the rest F16 the last one is even connected over cable-internet and sychronized to the host-ntpd which has the same time sources as all other guests over openVPN the problem happens only on F16 guests so i see no time-config problem here the 6 seconds difference are the ssh-logins on the machines Mo 26. Mär 20:40:41 CEST 2012 Mo 26. Mär 20:40:41 CEST 2012 Mo 26. Mär 20:40:41 CEST 2012 Mo 26. Mär 20:40:42 CEST 2012 Mo 26. Mär 20:40:42 CEST 2012 Mo 26. Mär 20:40:42 CEST 2012 Mo 26. Mär 20:40:43 CEST 2012 Mo 26. Mär 20:40:43 CEST 2012 Mo 26. Mär 20:40:43 CEST 2012 Mo 26. Mär 20:40:44 CEST 2012 Mo 26. Mär 20:40:44 CEST 2012 Mo 26. Mär 20:40:44 CEST 2012 Mo 26. Mär 20:40:45 CEST 2012 Mo 26. Mär 20:40:45 CEST 2012 Mo 26. Mär 20:40:46 CEST 2012 Mo 26. Mär 20:40:46 CEST 2012 Mo 26. Mär 20:40:47 CEST 2012 Mo 26. Mär 20:40:47 CEST 2012 Mo 26. Mär 20:40:47 CEST 2012 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
Richard W.M. Jones wrote: Is this really true? What happens if, say, your program depends on PCRE, which has different sonames on Debian/Ubuntu and Fedora (for essentially the same library): The same thing which happens if you build for, say, RHEL 6 on Fedora 16 using mock, pbuilder is the Debian equivalent to mock. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Mon, Mar 26, 2012 at 01:37:39PM -0400, DJ Delorie wrote: Which leads me to a rant about ARM. G RANT!! I didn't think I'd ever love the BIOS, but compared to the alternatives (UEFI and a million different ARM bootloaders) it's simple and effective. This is getting way off-topic, but... most linux-capable ARM chips support a BIOS in the pc sense. Vendors choose not to do it that way. Given that the pc sense of BIOS includes having arguments returned in x86 registers, I really don't think that's true. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Messaging SIG - IRC Meetings on Tuesdays
Just an announcement - the Messaging SIG is starting regular IRC meetings on Tuesdays at 16:00 UTC. Wiki page for the SIG: http://fedoraproject.org/wiki/Messaging_SIG My work on a proposal and a python library: https://github.com/ralphbean/fedmsg/blob/develop/doc/proposal.rst -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
Matthias Clasen wrote: The trick is to not build for rawhide ever, until after the stable release is out, and instead rely on inheritance. Since building everything twice is just a terrible waste of effort, and makes this whole mass building thing even more of a torture. But, of course, this only works if you get on the right track when doing the first build after the fork - unfortunately, our forking setup makes it not easy to avoid doing at least one accidental F18 build before you notice the new branch... I don't recommend relying on this, because underlying libraries can have different sonames in Rawhide than in the release. IMHO it's better to always build for Rawhide separately, even when not strictly necessary. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
Given that the pc sense of BIOS includes having arguments returned in x86 registers, I really don't think that's true. ARM has registers too... My point is, the ARM chips *do* support an on-board flash bootloader, and there's no reason why that bootloader couldn't export a standard ABI that uses interrupts and register passing, and boot off a standard attached disk... ... but that's not what the vendors do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
Rex Dieter wrote: the kde-sig has similar pain-points doing mass updates. Having a list of pkgs to build (seems done on google docs in your case already, good), and having your own koji tag/target does seem to simplify matters a bunch. Then it's relatively easy to compose a bodhi update from the output from: koji list-tagged --latest f16-gnome for example. Let's also mention our mass-update script: https://fedorahosted.org/kde-settings/browser/scripts which may or may not be of interest. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
The following is going to kill pretty much every packaged webapp unless they are changed now: https://httpd.apache.org/docs/2.4/upgrading.html#access -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: last superblock write time in future
Reindl Harald wrote: i notice this since upgraded to Fedora 16 on mostly all virtual machines while i have never seeen this with F15 When did you see that? Yesterday? Might that be related to DST (Daylight Savings Time, or Dumb Sucker Time as I like to call it ;-) )? Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Dependencies on Bodhi Updates
As requested during the FESCo meeting, I am going to try to summarize some of the issues inherent in the way that Bodhi updates currently work. First, I'll try to explain the goals and constraints: 1) The stable 'fedora-updates' yum repository should NEVER exist in a state where any package has dependency issues. In other words, it should never be possible for an update to be pushed to stable that breaks cleanly updating any other package. 2) Updates must be possible and (ideally) timely. This is probably self-evident. 3) Packages pushed to the stable 'fedora-updates' yum repository should (ideally) not introduce regressions in packages that depend on them. 4) New features in superpackages such as Firefox, GNOME or FreeIPA that have many and varied dependencies may require new features in packages they depend on in order to enhance or fix the superpackage. In the trivial example, a package (let's say libtalloc) needs to make an update to fix a bug. This package requires nothing new from its dependencies and is a self-contained fix. For this example, it is simple to just build libtalloc in koji and then create a Bodhi update and pass it through updates-testing, get karma and *poof* off to fedora-updates. Now let's extend the example. Suppose that we have another package libtevent that has libtalloc as a dependency. Libtevent's maintainer wants to add a new feature to libtevent, but the patch from upstream depends on the bug in libtalloc having been fixed in order for the new feature to work properly. In this situation, the maintainer of libtevent would build libtevent with an explicit Requires: libtalloc = version in the specfile (possibly pulling libtalloc into the BuildRoot overrides if necessary) and then test it locally to see that it works. So now we have our first updates dependency issue. If we submit libtevent as its own update, it is possible that it will achieve its karma requirement before libtalloc does. It would then be pushed to the fedora-updates repository and then introduce a dependency issue in the stable repository (because users trying to update libtevent would be unable to update libtalloc without enabling the updates-testing repository). The current recommended approach is to bundle the two updates into a single one carrying multiple packages. The first problem with this is that you must have commit privilege on all packages that you are bundling into an update. If you do not, then you need to track down a provenpackager to do it for you. Now let's make the problem even more fun. Consider that the update to libtevent might be coming in because it is necessary for a new feature in libldb, which is in turn providing new functionality necessary for SSSD. So now we have four packages all sitting in the same update. The problem with this is that the tendency will be to only test the most user-visible package(s) in the set. In this particular case, that might be SSSD. So people would likely test SSSD and, if nothing went wrong, consider the entire update stable. But wait! SSSD isn't the only package that depends on libldb, libtevent and libtalloc. So too does the samba package. Suppose that the bugfix in libtalloc, after resolving the original issue, results in exposing another more serious bug in samba? Now we need to pull a samba update into this same update series. A contrived example, you say? That would never happen, bugfixes aren't likely to do that. Well, for one example: https://admin.fedoraproject.org/updates/FEDORA-2011-11845 In this particular example, we knew up-front that it was going to necessitate a rebuild of several dependent packages and we coordinated a single release to address them. So in this case, the proper approach was to bundle them together in a single update. This worked because we specifically knew that the libtevent change was going to break other packages. But what about when we don't know that? Let's take another example: https://admin.fedoraproject.org/updates/FEDORA-2011-17399 In this case, there was a security bug reported against Firefox. Such things are serious, and acted on quickly. However, the bug was actually fixed in the nss package, and Firefox, Xulrunner and friends were rebuilt against that nss package. The problem was this: the fix made to the nss package introduced regressions in every other package that depended on it. However, because the default install of Firefox contained no issues, it rapidly received the necessary karma points and the whole update was pushed to stable. It then broke nearly every application in Fedora that relied on cryptography. The problem here was sociological, not technological. The only package that received testing was Firefox. It's hard to say without evidence whether the problem would have been averted by having nss go through its own update, but I strongly suspect that what we would have seen was greater testing on actual nss features for that specific update. Of course, we now have the same
urandom vs haveged
Performance: dd if=/dev/zero ~56MB/s CPU 10% dd if=/dev/urandom ~12MB/s CPU 99% haveged ~54MB/s CPU 25% The dd relative values are consistent with kernels in Fedora 16. However these tests were done with 3.3.0-1. The questions are: Is the urandom performance expected? What is the quality of pseudo-random data produced by urandom vs haveged? If the qualities are similar, or haveged's is better, is there anything that can be done to improve urandom's performance? It really takes quite a bit longer to prepare a disk/volume for encryption. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
Once upon a time, Nicolas Mailhot nicolas.mail...@laposte.net said: The following is going to kill pretty much every packaged webapp unless they are changed now: https://httpd.apache.org/docs/2.4/upgrading.html#access Did you read this part: The old access control idioms should be replaced by the new authentication mechanisms, although for compatibility with old configurations, the new module mod_access_compat is provided. It would be easy to include mod_access_compat in the Fedora default config for a release or two while the compat config is deprecated (and noted in the release notes as such). -- 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: Dependencies on Bodhi Updates
Stephen Gallagher wrote: 2) We could continue on the single update for multiple packages approach, but revamp the karma system so that each SRPM gets its own karma, rather than the update as a whole. Then, the whole update would not be pushed via autokarma until all of the dependent packages had sufficient karma (or the owner of the update could push them after the stable wait period, of course). This just does not scale for large update groups such as the KDE SC updates. I think it would also acerbate the already existing How do I provide feedback for a library? problem (because now it'd also affect libraries included in update groups, not just those filed separately). I don't understand why we need to make up more and more complicated rules for updates rather than just killing the whole karma and autokarma business and having the maintainer READ the update feedback and make an informed (and unhindered by bureaucracy) decision based on that. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16: Kernel bug with USB disks ?
On 03/26/2012 06:05 AM, Terry Barnaby wrote: Hi, I am using the latest F16 kernel: 3.3.0-4.fc16.i686.PAE and am having problems with a MicroSD card connected to a USB card reader. This has been working fine until recently (at least in F14 on the same hardware). The problem is that umount does not appear to be working correctly. I have an ext3 file system on the card. I can mount it, and I can copy files to it. However when I use the umount ... command it returns instantly (should sync the files to the card). The system says the card is unmounted (at least it is not listed with mount, df etc). However if I run sync, there is a lot of disk activity to the card ... Also if I try and run mkfs it says the device in in use ... If I mount a blank card it lists the files present on the previous card ... This sounds like a nasty kernel bug ... Anyone else seen this ? I thought I'd noticed something like this with 3.2.x kernels also; I couldn't narrow it down more than that. In my case, it's a USB external HDD. After unmounting, I have an old habit of running 3 syncs in one line. And lately, I've noticed that I don't even get that disk activity until I give it a second trio of syncs, which certainly doesn't seem right. Let me check right now with 3.3.0-4... Odd, now I do get the activity at about the same time as the umount, and no further activity when I issue the syncs. Seems to be the opposite of what you've reported. -- J. Randall Owens | http://www.ghiapet.net/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Dependencies on Bodhi Updates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26.03.2012 21:53, Stephen Gallagher wrote: So now we have our first updates dependency issue. If we submit libtevent as its own update, it is possible that it will achieve its karma requirement before libtalloc does. It would then be pushed to the fedora-updates repository and then introduce a dependency issue in the stable repository (because users trying to update libtevent would be unable to update libtalloc without enabling the updates-testing repository). The current recommended approach is to bundle the two updates into a single one carrying multiple packages. The first problem with this is that you must have commit privilege on all packages that you are bundling into an update. If you do not, then you need to track down a provenpackager to do it for you. Thank you for your post about this topic. In this year we have as a minimum two cases were we have got broken dependencies in the F-16 stable repository. 1.) alsa-utils and alsa-libs was pushed out of sync 2.) gcc and llvm which requires as specific version of gcc was pushed out of sync. The issue is, that the user will get an ugly error message which is not a good advertisement for the Fedora project. I have wrote mails to the maintainers and in the second case I have got the feeling, that the maintainer didn't understood my complain. Of course we can get run in error if the push fails due an technical issue, but this is an onther topic. Best Regards: Jochen Schmitt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iJwEAQECAAYFAk9w0cYACgkQZLAIBz9lVu+lVAP9F50AXP0B5nDHWvFuxRd4f5wY UyZz2gkNi7CMX5jD9DkkzQ+swrrvEVOQCpUA4zOplP3bsEpR8MV8i4Y104gz8Ygw cCg/V8xhEMfalhJ3ORDST6yVLlBViHKsjOcV0tJ0fAFX10zShxXwlnxutp+RP8V2 MKT4JUhj1lD8knqWo50= =XZBT -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
orphaning bibus
I don't really use it anymore (replaced it with Zotero) and don't have time to maintain it, but it is still being developed upstream (as of late 2011): http://sourceforge.net/projects/bibus-biblio/ There is a 1.5.2 release available, see also: https://bugzilla.redhat.com/show_bug.cgi?id=757675 Hopefully it will go to a better home. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: orphaning bibus
Pkgdb link: https://admin.fedoraproject.org/pkgdb/acls/name/bibus I kept myself on as a co-maintainer, but it deserves a more proactive main owner. - Original Message - I don't really use it anymore (replaced it with Zotero) and don't have time to maintain it, but it is still being developed upstream (as of late 2011): http://sourceforge.net/projects/bibus-biblio/ There is a 1.5.2 release available, see also: https://bugzilla.redhat.com/show_bug.cgi?id=757675 Hopefully it will go to a better home. Alex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: ARM as a primary architecture
On Mon, Mar 26, 2012 at 03:32:15PM -0400, DJ Delorie wrote: Given that the pc sense of BIOS includes having arguments returned in x86 registers, I really don't think that's true. ARM has registers too... My point is, the ARM chips *do* support an on-board flash bootloader, and there's no reason why that bootloader couldn't export a standard ABI that uses interrupts and register passing, and boot off a standard attached disk... I think you misunderstood Richard. ARM hardware is moving towards adopting UEFI as the standard firmware interface, which is BIOS-like in the sense that you're describing. Richard was explicitly talking about BIOS-as-in-x86-asm-and-int-calls being preferable to UEFI. There's no real way ARM could implement the latter. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
On Mon, Mar 26, 2012 at 12:49:32PM +0100, Richard Hughes wrote: On 26 March 2012 11:58, Peter Robinson pbrobin...@gmail.com wrote: It would be nice if the rawhide stream was built at the same time as well as not doing so has the effect of people trying to work with rawhide as well get random failures and in the process of building F-17 and rawhide on ARM a non insignificant number of gnome packages have newer builds in F-16 than they do in both rawhide and F-17 that I've ended up having to fix. Yes, this is a valid critisism. I'm hoping to write a tool to automatically update GNOME builds in a stable release and in rawhide (that watches ftp-release list), rather than having to do it all manually. If you want ideas: http://svnweb.mageia.org/soft/mga-gnome/trunk/mga-gnome?view=markup Though note that Mageia packages per .so library version, so any bumps = breakage (on purpose, goes in another package) Also, if you need more information on ftp.gnome.org or in ftp-release-list: http://git.gnome.org/browse/sysadmin-bin/tree/ftpadmin Still want: - One (preferably json) file on ftp.gnome.org containing all latest versions of all modules. Problem is that master.gnome.org uses NFS and bit worried about how to update such a file nicely. - An RSS feed again (apparently there is some django module which makes this easy; needs to be available for RHEL6/EPEL6). -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
On Monday, 26 בMarch 2012 11:32:10 Richard W.M. Jones wrote: On Mon, Mar 26, 2012 at 12:57:44AM +0200, Oron Peled wrote: - This means that a Debian/Ubuntu workstation can build both .deb and RPM packages, and we cannot use Fedora for a similar role. Is this really true? What happens if, say, your program depends on PCRE, which has different sonames on Debian/Ubuntu and Fedora (for essentially the same library): You are correct that packaging tools by themselves do not solve *all* portability problems (e.g: Suse/Mandriva/Feodra use RPM, but nobody sane would try to install cross-distro -- even with same package format) However, there are many important working use-cases. Examples: * If the programs or libraries you compile yourselve, use just glibc, you are normally good to go (due to the very strict ABI provided by glibc): oron@squeeze1:~$ objdump --all /lib/libc-2.11.3.so | grep SONAME SONAME libc.so.6 [oron@localhost ~]$ rpm -q fedora-release fedora-release-15-3.noarch [oron@localhost ~]$ objdump --all /lib/libc-2.14.1.so | grep SONAME SONAME libc.so.6 * Noarch packages (perl/python/ruby/you-name-it) * Packaging cross-compiler toolchain/libraries (which is really a special case of the two previous items) * Manipulating packages: - createrepo - downloading/extracting source packages I don't understand how a binary built on one platform could be copied across to the other and work. Moreover, if we have pbuilder on Fedora (which is one of the packages I listed), we are done, as it build in a chroot environment (similar to Fedora's mock). Actually, even when building on a Debian host I always use either pbuilder(1) for unattended builds, or build in an schroot(1) for interactive builds. This enables me to build the same source tree (maybe with pending commits) for different OS releases. [Note: schroot(1) is already packaged in Fedora -- anybody who didn't try it is missing a crown jewl] -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron The future is here, it's just not evenly distributed yet. - William Gibson -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: Connotation analysis for Fedora Project codenames
This discussion started on the board list yet I know a lot of developers have an opinion on the topic. The deadline for F18 name ideas is almost over but the discussion is still valid. Join the board list and speak up! Fedora is supposed to be community driven, take the wheel. -- Bob - Forwarded Message - From: Jaroslav Reznik jrez...@redhat.com To: Fedora community advisory board advisory-bo...@lists.fedoraproject.org Sent: Friday, March 23, 2012 9:14:36 AM GMT -06:00 US/Canada Central Subject: Connotation analysis for Fedora Project codenames Hi, there's ongoing discussion about the connotation analysis of Fedora Project code names (so not only for Fedora itself but other sub-projects too) started by Rajesh Ranjan (thanks for ticket!). It's a right time to get an input from community as there's currently running Fedora 18 codename process [1]. As Rajesh posted to Fedora Board Track ticket, connotation is the emotional and imaginative association for a word, where denotation is the strict dictionary meaning of a word. Current process for selecting next code name is - community members suggests the name, there's publicly accessible list for everyone, then Board goes through the suggested names list to remove the clear examples of names breaking the policy (yeah, usually it's one search term in Google to find out the name has to be ruled out, but that's Board deal ;-) and this list is sent to Red Hat legal for proper legal review. Then the voting is opened for everyone with valid FAS account and only names that passed the process are allowed. In Fedora we believe in freedom and openness, we don't have to stick to the strict corporate-like| rules but on the other hand we should respect our community and we don't want to offend anyone consciously. Usually, we use the common sense to rule out offending stuff but also we (and Board neither) don't have a degree in sociology, politics, religion and our geek culture is also from the another universe :). As I already pointed out - the process is open. Anybody can step into in the early phase of naming selection and comment the potential problems. And I believe the Board members will think about the concerns raised (at least me ;-). So personally I'd like to avoid any strict rule/policy as it could hurt our community, we don't have a proper set of skills to do the full analysis during the Board turn and I really hope with help provided by community we can avoid the naming problems in the future - just we need your, community, input. Any thoughts? PS: I like Christoph's comment in ticket - that as an international project we should be proud of our diversity. It is a chance and a burden at the same time, Fedora will face this problem often and we can do our best to respect others and their views. Jaroslav [1] http://fedoraproject.org/wiki/Name_suggestions_for_Fedora_18 ___ advisory-board mailing list advisory-bo...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/advisory-board -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urandom vs haveged
On 03/26/2012 08:56 PM, Chris Murphy wrote: Performance: dd if=/dev/zero ~56MB/s CPU 10% dd if=/dev/urandom~12MB/s CPU 99% haveged ~54MB/s CPU 25% The dd relative values are consistent with kernels in Fedora 16. However these tests were done with 3.3.0-1. The questions are: Is the urandom performance expected? What is the quality of pseudo-random data produced by urandom vs haveged? If the qualities are similar, or haveged's is better, is there anything that can be done to improve urandom's performance? It really takes quite a bit longer to prepare a disk/volume for encryption. Well if you're just writing huge amounts of random data to clear existing space, then you don't need it to be cryptographically secure. Why are you doing this exactly? Would /dev/zero suffice? In any case it seems you could use shred rather than dd to clear data? It has been changed to use a much faster internal generator: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=v7.2-21-gaf5723c cheers, Pádraig. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
On Monday, 26 בMarch 2012 13:08:33 Jeroen van Meeuwen (Kolab Systems) wrote: I'm still interested in making available the packages through Fedora repositories proper, but I'm also, admittedly, not paying attention to the review tickets. I have what I need (rubygem-passenger and many others included), and while I'd like Fedora to also make available what I have, I have little interest in completing the slow, lengthy, scrutinizing and therefore painful and time-consuming review process. Understandable. Would you like to assign me as maintainer/co-maintainer? My plan is: - Refresh build for Fedora/rawhide - Refresh source version to what exist in Debian/squeeze as a minimum. (I think Debian/testing [wheezy] is a better match for Fedora release cycle, but I prefer to be conservative at the beginning) - Go through the review process. So, will I get this hot-potato? -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron In theory, it's practical. In practice - it's only a theory. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dh-make broken deps for 3 releases (was: F-17 Branched report: 20120325 changes)
I don't want it to sounds like I'm discouraging anyone from packaging these. I'm a well-known packaging maximalist :-) If they even let me do 'dpkg-deb -c ...' then there is some use for them. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Managing the GNOME updates in Fedora
On Mon, 2012-03-26 at 11:52 +0100, Richard Hughes wrote: At the moment the GNOME updates in Fedora are a bit of chaotic affair. They mostly work, but only because of people like mclasen who spend hours and hours building packages and putting everything together manually. For 3.3.92 I experimented doing a mega-update and trying to get all the 3.3.92 builds in one place, and working with kalev on a google spreadsheet to make sure everything was built in good time, and nothing was left behind. For the GNOME 3.4.0 release, I'm asking people to copy this pattern, and try to get all the builds into *one* update rather than 90% of the builds in one mega-update and then 10% in random updates that other people have filed. If this works, I'm intending to do the 3.4.1 update as one update as well. So, TLDR. If you're packaging a GNOME package that's just had a 3.3.92 upstream release and is about to have a 3.4.0 release, please build the package like normal, but don't file an update. Instead add the build ID to https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc and then I'll pick up the build for the mega update. Hopefully this makes the updates system easier to QA, as GNOME is more and more interconnected, and it' just not possible to QA updates when you have a 3.3.91 version of gnome-settings-daemon and 3.4.1 version of gnome-screenshot. Thanks a lot for this, Richard. It'll make QAing the updates much more manageable. -- 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: httpd 2.4 is coming, RFC on module packaging draft
On 03/26/2012 10:10 PM, Michał Piotrowski wrote: 2012/3/26 Nicolas Mailhot nicolas.mail...@laposte.net: The following is going to kill pretty much every packaged webapp unless they are changed now: https://httpd.apache.org/docs/2.4/upgrading.html#access IMHO mod_access_compat should be enabled by default https://httpd.apache.org/docs/2.4/mod/mod_access_compat.html I disagree. Since this is a major update that gets introduced together with a new Fedora version this opportunity should be used to make switches like these. Otherwise you'll be forced to either keep this compat stuff around for a long time (given the long apache release cycles) or remove it with a minor update when people least expect it. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: I disagree. Since this is a major update that gets introduced together with a new Fedora version this opportunity should be used to make switches like these. In principle I agree with what you're saying, but this is still going to require changing lots of packages, and it should be properly scoped on the httpd 2.4 feature page. Here's what I plan to use in Cacti. Directory /usr/share/cacti/ IfVersion 2.2 Require host localhost /IfVersion IfVersion = 2.2 Order deny,allow Deny from all Allow from localhost /IfVersion /Directory -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: httpd 2.4 is coming, RFC on module packaging draft
On 03/27/2012 03:54 AM, Ken Dreyer wrote: On Mon, Mar 26, 2012 at 6:53 PM, Dennis Jacobfeuerborn denni...@conversis.de wrote: I disagree. Since this is a major update that gets introduced together with a new Fedora version this opportunity should be used to make switches like these. In principle I agree with what you're saying, but this is still going to require changing lots of packages, and it should be properly scoped on the httpd 2.4 feature page. All the more reason for making this change now with a major version change and early in the F18 release cycle rather than being forced to go through this in a later supposedly minor update. Here's what I plan to use in Cacti. Directory /usr/share/cacti/ IfVersion 2.2 Require host localhost /IfVersion IfVersion = 2.2 Order deny,allow Deny from all Allow from localhost /IfVersion /Directory I don't think making this a runtime configuration is a good idea. Most people only run either 2.2 or 2.4 but not both so having this in their config is really unnecessary and makes things more complicated then it needs to be. Why not make this distinction in the spec file and include one of two configuration files in the rpm depending on the release version? That way F18+ users get a clean config for 2.4 and older version get a clean config for 2.2. Regards, Dennis -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: urandom vs haveged
On Mon, Mar 26, 2012 at 6:55 PM, Chris Murphy li...@colorremedies.com wrote: So then the question is, if urandom is what's recommended, are faster substitutes just as good? If they are just as good, then why aren't they the first recommendation? And if this step is superfluous, then I'd suggest documentation be changed to eliminate the suggestion altogether. Personally, I setup dmcrypt (w/o luks) first using /dev/urandom as the key and one of the secure block modes (e.g. aes-lrw or aes-essiv). Then I fill the dmcrypt device with /dev/zero. This goes fairly fast, filling the device with securely encrypted zeros. Then I drop the volume and set up luks normally. From a security perspective an attack which allowed the attacker to distinguish the randomly encrypted /dev/zero from your other data would be a fairly bad vulnerability generally against the encrypted volume... much worse than the information leak wrt used blocks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Test-Unit-Lite-0.1201.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Unit-Lite: eda35ad122e70050b6e5f966b53d3b9e Test-Unit-Lite-0.1201.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-Test-Unit-Lite] Update to 0.1201
commit 3b12ef404c4cd2e039e487413873ae514f15ca65
Author: Paul Howarth p...@city-fan.org
Date: Mon Mar 26 09:38:43 2012 +0100
Update to 0.1201
- New upstream release 0.1201
- Repackaged with newer Module::Builder
perl-Test-Unit-Lite.spec | 13 ++---
sources |2 +-
2 files changed, 11 insertions(+), 4 deletions(-)
---
diff --git a/perl-Test-Unit-Lite.spec b/perl-Test-Unit-Lite.spec
index ddd3dcd..afb0fc2 100644
--- a/perl-Test-Unit-Lite.spec
+++ b/perl-Test-Unit-Lite.spec
@@ -1,12 +1,15 @@
+# Perl and RPM versioning don't work the same :-(
+%global extraversion 01
+
Name: perl-Test-Unit-Lite
Epoch: 1
Version: 0.12
-Release: 11%{?dist}
+Release: 12%{?dist}
Summary: Unit testing without external dependencies
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Test-Unit-Lite/
-Source0:
http://search.cpan.org/CPAN/authors/id/D/DE/DEXTER/Test-Unit-Lite-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/D/DE/DEXTER/Test-Unit-Lite-%{version}%{?extraversion}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
BuildRequires: perl(base)
@@ -31,7 +34,7 @@ Test::Unit. It doesn't implement all classes and methods at
100% and only
those necessary to run tests are available.
%prep
-%setup -q -n Test-Unit-Lite-%{version}
+%setup -q -n Test-Unit-Lite-%{version}%{?extraversion}
# Filter unwanted provides and (prior to rpm 4.9)
# Unwanted requires not actually detected prior to rpm 4.9
@@ -59,6 +62,10 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Unit::Lite.3pm*
%changelog
+* Sun Mar 25 2012 Paul Howarth p...@city-fan.org - 1:0.12-12
+- Update to 0.1201
+ - Repackaged with newer Module::Builder
+
* Sat Mar 24 2012 Paul Howarth p...@city-fan.org - 1:0.12-11
- Add buildreqs for Perl core modules that could be dual-lived
- Don't need to remove empty directories from buildroot
diff --git a/sources b/sources
index 8df1581..bb9cec2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4490b5f67ea6ded89d9dd6d39ce9787f Test-Unit-Lite-0.12.tar.gz
+eda35ad122e70050b6e5f966b53d3b9e Test-Unit-Lite-0.1201.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-Test-Unit-Lite] Created tag perl-Test-Unit-Lite-0.12-12.fc18
The lightweight tag 'perl-Test-Unit-Lite-0.12-12.fc18' was created pointing to: 3b12ef4... Update to 0.1201 -- 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 URI-1.60.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-URI: 70f739be8ce28b8baba7c5920ffee4dc URI-1.60.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-URI] Update to 1.60
commit c68518da8f9f3906e88bd184cc1248495a7207a6
Author: Paul Howarth p...@city-fan.org
Date: Mon Mar 26 10:07:31 2012 +0100
Update to 1.60
- New upstream release 1.60
- Do not reverse the order of new parameters
- Avoid test failure if the local hostname is 'foo' (CPAN RT#75519)
- Work around a stupid join bug in 5.8.[12] (CPAN RT#59274)
- Updated repository URL
- Don't need to remove empty directories from buildroot
- BR: perl(constant)
perl-URI.spec | 17 +
sources |2 +-
2 files changed, 14 insertions(+), 5 deletions(-)
---
diff --git a/perl-URI.spec b/perl-URI.spec
index e57ad86..661d4f3 100644
--- a/perl-URI.spec
+++ b/perl-URI.spec
@@ -1,6 +1,6 @@
Name: perl-URI
-Version:1.59
-Release:3%{?dist}
+Version:1.60
+Release:1%{?dist}
Summary:A Perl module implementing URI parsing and manipulation
Group: Development/Libraries
License:GPL+ or Artistic
@@ -8,6 +8,7 @@ URL:http://search.cpan.org/dist/URI/
Source0:http://www.cpan.org/authors/id/G/GA/GAAS/URI-%{version}.tar.gz
BuildArch: noarch
BuildRequires: perl(Carp)
+BuildRequires: perl(constant)
BuildRequires: perl(Exporter)
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(MIME::Base64)
@@ -25,7 +26,7 @@ updated by RFC 2732).
%prep
%setup -q -n URI-%{version}
-chmod 644 uri-test
+chmod -c 644 uri-test
%build
perl Makefile.PL INSTALLDIRS=perl
@@ -34,7 +35,6 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -type d -depth -exec rmdir {} ';' 2/dev/null
%{_fixperms} %{buildroot}
%check
@@ -57,6 +57,15 @@ make test
%{_mandir}/man3/URI::ldap.3pm*
%changelog
+* Mon Mar 26 2012 Paul Howarth p...@city-fan.org - 1.60-1
+- Update to 1.60
+ - Do not reverse the order of new parameters
+ - Avoid test failure if the local hostname is 'foo' (CPAN RT#75519)
+ - Work around a stupid join bug in 5.8.[12] (CPAN RT#59274)
+ - Updated repository URL
+- Don't need to remove empty directories from buildroot
+- BR: perl(constant)
+
* Fri Jan 20 2012 Paul Howarth p...@city-fan.org - 1.59-3
- Break build dependency loop by only using perl(Business::ISBN) if we're not
bootstrapping
diff --git a/sources b/sources
index c200c70..e2dad49 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fecebf8fa20e2d26ea4a1649c095e96e URI-1.59.tar.gz
+70f739be8ce28b8baba7c5920ffee4dc URI-1.60.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-URI/f17] Update to 1.60
Summary of changes: c68518d... Update to 1.60 (*) (*) 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
[perl-URI] Created tag perl-URI-1.60-1.fc17
The lightweight tag 'perl-URI-1.60-1.fc17' was created pointing to: c68518d... Update to 1.60 -- 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-URI] Created tag perl-URI-1.60-1.fc18
The lightweight tag 'perl-URI-1.60-1.fc18' was created pointing to: c68518d... Update to 1.60 -- 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 B-Utils-0.21.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-B-Utils: 5e6af42f436918253137d367b52478cd B-Utils-0.21.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-B-Utils] update to 0.21
commit 20a94a6d4ab89175fd731a120adaf51697b8c76e
Author: Iain Arnell iarn...@gmail.com
Date: Mon Mar 26 05:22:24 2012 -0600
update to 0.21
.gitignore|1 +
perl-B-Utils.spec |6 --
sources |2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 84359eb..1774cad 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ B-Utils-0.11.tar.gz
/B-Utils-0.15.tar.gz
/B-Utils-0.17.tar.gz
/B-Utils-0.19.tar.gz
+/B-Utils-0.21.tar.gz
diff --git a/perl-B-Utils.spec b/perl-B-Utils.spec
index e7cb847..70b3280 100644
--- a/perl-B-Utils.spec
+++ b/perl-B-Utils.spec
@@ -1,5 +1,5 @@
Name: perl-B-Utils
-Version:0.19
+Version:0.21
Release:1%{?dist}
Summary:Helper functions for op tree manipulation
License:GPL+ or Artistic
@@ -18,7 +18,6 @@ BuildRequires: perl(List::Util)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(strict)
BuildRequires: perl(subs)
-BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::More)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(vars)
@@ -57,6 +56,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 26 2012 Iain Arnell iarn...@gmail.com 0.21-1
+- update to latest upstream version
+
* Mon Mar 12 2012 Iain Arnell iarn...@gmail.com 0.19-1
- update to latest upstream version
diff --git a/sources b/sources
index de8d223..d7bfb9e 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b231d09deb80b0633b14317dc8e36aa2 B-Utils-0.19.tar.gz
+5e6af42f436918253137d367b52478cd B-Utils-0.21.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-Tie-RefHash-Weak] Spec clean-up
commit 9c97ff7e83379604d23898e66bfdd6f3d9751beb
Author: Paul Howarth p...@city-fan.org
Date: Mon Mar 26 14:13:57 2012 +0100
Spec clean-up
- BR: perl(base), perl(Exporter), perl(Scalar::Util), perl(Tie::RefHash) ≥
1.34
- Don't use macros for commands
- Drop %defattr, redundant since rpm 4.4
- Make %files list more explicit
- Don't need to remove empty directories from buildroot
- Use DESTDIR rather than PERL_INSTALL_ROOT
- Use tabs
.gitignore |2 +-
perl-Tie-RefHash-Weak.spec | 72 ---
2 files changed, 41 insertions(+), 33 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 8dae941..4a947a2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1 @@
-Tie-RefHash-Weak-0.09.tar.gz
+/Tie-RefHash-Weak-[0-9.]*.tar.gz
diff --git a/perl-Tie-RefHash-Weak.spec b/perl-Tie-RefHash-Weak.spec
index 5f66afe..5e673e2 100644
--- a/perl-Tie-RefHash-Weak.spec
+++ b/perl-Tie-RefHash-Weak.spec
@@ -1,18 +1,22 @@
-Name: perl-Tie-RefHash-Weak
-Version:0.09
-Release:9%{?dist}
-Summary:Tie::RefHash subclass with weakened references in the keys
-License:GPL+ or Artistic
-Group: Development/Libraries
-URL:http://search.cpan.org/dist/Tie-RefHash-Weak/
-Source0:
http://www.cpan.org/authors/id/N/NU/NUFFIN/Tie-RefHash-Weak-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-BuildArch: noarch
-BuildRequires: perl(ExtUtils::MakeMaker)
-BuildRequires: perl(Task::Weaken)
-BuildRequires: perl(Variable::Magic)
-BuildRequires: perl(Test::More)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Name: perl-Tie-RefHash-Weak
+Version: 0.09
+Release: 10%{?dist}
+Summary: Tie::RefHash subclass with weakened references in the keys
+License: GPL+ or Artistic
+Group: Development/Libraries
+URL: http://search.cpan.org/dist/Tie-RefHash-Weak/
+Source0:
http://search.cpan.org/CPAN/authors/id/N/NU/NUFFIN/Tie-RefHash-Weak-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
+BuildArch: noarch
+BuildRequires: perl(base)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Task::Weaken)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Tie::RefHash) = 1.34
+BuildRequires: perl(Variable::Magic)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
The Tie::RefHash module can be used to access hashes by reference. This is
@@ -22,32 +26,36 @@ useful when you index by object, for example.
%setup -q -n Tie-RefHash-Weak-%{version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor
+perl Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
-
-find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
-
-%{_fixperms} $RPM_BUILD_ROOT/*
+rm -rf %{buildroot}
+make pure_install DESTDIR=%{buildroot}
+find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
+%{_fixperms} %{buildroot}
%check
make test
%clean
-rm -rf $RPM_BUILD_ROOT
+rm -rf %{buildroot}
%files
-%defattr(-,root,root,-)
%doc Changes TODO
-%{perl_vendorlib}/*
-%{_mandir}/man3/*
+%{perl_vendorlib}/Tie/
+%{_mandir}/man3/Tie::RefHash::Weak.3pm*
%changelog
+* Mon Mar 26 2012 Paul Howarth p...@city-fan.org - 0.09-10
+- BR: perl(base), perl(Exporter), perl(Scalar::Util), perl(Tie::RefHash) ≥ 1.34
+- Don't use macros for commands
+- Drop %%defattr, redundant since rpm 4.4
+- Make %%files list more explicit
+- Don't need to remove empty directories from buildroot
+- Use DESTDIR rather than PERL_INSTALL_ROOT
+- Use tabs
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.09-9
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
@@ -58,13 +66,13 @@ rm -rf $RPM_BUILD_ROOT
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
* Thu Dec 23 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-6
-- 661697 rebuild for fixing problems with vendorach/lib
+- Rebuild to fix problems with vendorarch/lib (#661697)
* Fri May 07 2010 Marcela Maslanova mmasl...@redhat.com - 0.09-5
- Mass rebuild with perl-5.12.0
* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 0.09-4
-- rebuild against perl 5.10.1
+- Rebuild against perl 5.10.1
* Sun Jul 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.09-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild
@@ -72,5 +80,5 @@ rm -rf $RPM_BUILD_ROOT
* Thu Feb 26 2009 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.09-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild
-* Thu Feb 05 2009
[perl-Test-use-ok] Created tag perl-Test-use-ok-0.02-13.el5
The lightweight tag 'perl-Test-use-ok-0.02-13.el5' was created pointing to: 475c162... Spec clean-up -- 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-Tie-RefHash-Weak] Created tag perl-Tie-RefHash-Weak-0.09-10.fc17
The lightweight tag 'perl-Tie-RefHash-Weak-0.09-10.fc17' was created pointing to: 9c97ff7... Spec clean-up -- 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-Tie-RefHash-Weak] Created tag perl-Tie-RefHash-Weak-0.09-10.fc18
The lightweight tag 'perl-Tie-RefHash-Weak-0.09-10.fc18' was created pointing to: 9c97ff7... Spec clean-up -- 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 806922] New: perl-Socket-2.000-2 does not build in ARM Koji
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-Socket-2.000-2 does not build in ARM Koji https://bugzilla.redhat.com/show_bug.cgi?id=806922 Summary: perl-Socket-2.000-2 does not build in ARM Koji Product: Fedora Version: 17 Platform: arm OS/Version: Linux Status: NEW Severity: unspecified Priority: unspecified Component: perl-Socket AssignedTo: ppi...@redhat.com ReportedBy: ppi...@redhat.com QAContact: extras...@fedoraproject.org CC: fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com, ppi...@redhat.com Classification: Fedora Story Points: --- Type: --- Regression: --- Mount Type: --- Documentation: --- Some t/sockaddr.t tests fails (http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=649875): PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/getaddrinfo.t .. ok t/getnameinfo.t .. ok t/ipv6_mreq.t ok t/sockaddr.t . Failed 4/31 subtests t/Socket.t ... ok t/socketpair.t ... ok Test Summary Report --- t/sockaddr.t (Wstat: 11 Tests: 27 Failed: 0) Non-zero wait status: 11 Parse errors: Bad plan. You planned 31 tests but ran 27. Files=6, Tests=124, 4 wallclock secs ( 0.20 usr 0.05 sys + 1.04 cusr 0.08 csys = 1.37 CPU) Result: FAIL I cannot reproduce it with up-to-date F17 ARMv7 machine locally. It fails in Koji only. -- 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 806922] perl-Socket-2.000-2 does not build in ARM Koji
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=806922 --- Comment #1 from Petr Pisar ppi...@redhat.com 2012-03-26 10:24:05 EDT --- The built root differences are gcc: 4.7.0-0.20.fc17 vs. 4.7.0-1.fc17 rpm-build: 4.9.1.2-12.fc17 vs. 4.9.1.2-14.fc17 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Sane-0.04.tar.gz uploaded to lookaside cache by bjohnson
A file has been added to the lookaside cache for perl-Sane: ac2a8fdeefd5f492adb4ee43eccaaad8 Sane-0.04.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-Sane] v 0.04
commit 8809744f56b6faac4b44c9b0d7ef05fcade9df22
Author: Bernard Johnson bjohn...@symetrix.com
Date: Mon Mar 26 08:40:39 2012 -0600
v 0.04
.gitignore |1 +
perl-Sane.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index baedea4..ff0737f 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
Sane-0.03.tar.gz
+/Sane-0.04.tar.gz
diff --git a/perl-Sane.spec b/perl-Sane.spec
index aef3032..1ad0f2f 100644
--- a/perl-Sane.spec
+++ b/perl-Sane.spec
@@ -1,6 +1,6 @@
Name: perl-Sane
-Version:0.03
-Release:8%{?dist}
+Version:0.04
+Release:1%{?dist}
Summary:Perl extension for the SANE (Scanner Access Now Easy) Project
Group: Development/Libraries
@@ -58,6 +58,9 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Mon Mar 26 2012 Bernard Johnson bjohn...@symetrix.com - 0.04-1
+- v 0.04
+
* Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.03-8
- Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild
diff --git a/sources b/sources
index d157f98..f1f7337 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-db83b8b07e1263b78187c4349a183082 Sane-0.03.tar.gz
+ac2a8fdeefd5f492adb4ee43eccaaad8 Sane-0.04.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
