Re: mounted external ext4 causes high kworker cpu
On Apr 27, 2012, at 9:53 AM, Jeff Moyer wrote: Chris Murphy li...@colorremedies.com writes: Normally top reports CPU line, sy at 0.4% when idle. If I format an external Firewire disk as btrfs and mount it, it remains at 0.4%. If I reformat as XFS and mount it, again top reports sy at 0.4%. However, if I reformat as ext4 and mount it, sy runs at 3.5%. These two processes are now at the top of top's results: kworker/1:2 kworker/0:4 Each uses on average 1.9% CPU. The light on the external drive flashes 4x per second. There are no processes using the disk at all while this is going on. If I umount it, the pulsing stops. If I remount it, the pulsing resumes as does the slightly higher CPU consumption. This doesn't happen with the same hardware mounted XFS or btrfs or HFS+. Odd? Sounds like lazy itable init. Try mkfs -t ext4 -E lazy_itable_init=0. This is happening on internal disks, targeted for Fedora installation. I can hear it once install is complete, still booted from DVD media. Is this a bug? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
Matthias Clasen wrote: We could easily drop some of less-than-half-complete translations to make room for a bit of minidebuginfo. Last time I looked, translations, fonts, etc made up upwards of 25% of the livecd. Or we could just drop the obsolescent cdrom size limitation... There are (almost) no translations on the KDE spin. They're all in kde-l10n-* packages which add up to almost the size of a CD on their own. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
Adam Jackson wrote: Even if all of your objections are true, and who knows, they might be: we already do provide alternatives. The Live media is not the only install media. The other alternatives are either already DVDs or netinstall CDs which require a fast Internet connection (which people who don't even have a DVD drive are unlikely to have). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
Alexander Larsson wrote: Its not particularly hard to strip the debuginfo when constructing the live image, although then installation from it will not really work as the rpms checksums will be wrong. Indeed, that doesn't sound like a sane solution to me. I'd rather we just don't add yet another size overhead to every package. Our packages keep growing and growing even without that. A few KiB here, a few KiB there, in many packages, adding up to a few MiB, and we keep running into size issues with our live image at every single release. Size matters! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Thu, May 10, 2012 at 4:17 AM, DJ Delorie d...@redhat.com wrote: Is LLVMpipe needed on, say, ARM? (Does anyone have a screenshot of GNOME Shell running on such a system?). Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg And currently OLPC uses gnome-panel although there is plans to move to gnome-shell. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
On Thu, 2012-05-10 at 10:02 +0200, drago01 wrote: On Thu, May 10, 2012 at 9:20 AM, Kevin Kofler kevin.kof...@chello.at wrote: I'd rather we just don't add yet another size overhead to every package. Our packages keep growing and growing even without that. A few KiB here, a few KiB there, in many packages, adding up to a few MiB, and we keep running into size issues with our live image at every single release. Size matters! Not really, you are restricting yourself by the artificial CD size limit. You don't have to use the full size of whatever bigger medium you choose (DVD, 1 or 2GB stick) but you are currently providing a poorer user experience because you insist on a medium from the last century. I agree, I think bumping the image size to 1GB and use DVD/mini-dvd/usb-stick is the sane way forward, since we consistently run into the cd limit and are forced to make changes that negatively affect the user experience in various ways. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
- Original Message - From: Jon Masters j...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Michel Alexandre Salim sali...@fedoraproject.org Sent: Wednesday, 9 May, 2012 10:57:30 PM Subject: Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Don't confuse llvm and clang, llvm has no equivalent in gcc world, clang is a C compiler like gcc that uses llvm tech. Apart from llvmpipe, we use llvm to execute vertex shaders on earlier AMD chipsets, newer AMD GPUs are also going to use llvm as the shader compiler backend for GLSL shaders. AMD also have open source OpenCL work in progress, that uses the GPU driver and LLVM. It probably makes sense that one of myself, ajax or glisse help out packaging llvm, but we aren't the most reliable people in terms of spare time to commit. Dave. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
drago01 wrote: Not really, you are restricting yourself by the artificial CD size limit. You don't have to use the full size of whatever bigger medium you choose (DVD, 1 or 2GB stick) but you are currently providing a poorer user experience because you insist on a medium from the last century. If every live image gets larger, that will also negatively affect the nice Multi Desktop Live DVDs the Ambassadors are now mass-producing. Those contain all our live CDs (all desktops in both 32-bit and 64-bit versions, where the bitness is autodetected at boot, but can be manually overridden) on one DVD, which is a great thing to hand out at events. We really shouldn't bloat our images just because we can. Downloading debugging information (and complete debugging information!) on demand is really the best solution. Or use the retrace server if you'd rather have a web service do the work for you. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rssh orphaned in Fedora
Hi Quick note: rssh has a security bug unfixed by upstream and has been orphaned https://bugzilla.redhat.com/show_bug.cgi?id=820415 Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120510 changes
Compose started at Thu May 10 08:15:05 UTC 2012 Broken deps for x86_64 -- [LuxRender] LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61 [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires rubygem(fastercsv) aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(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 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0 [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) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mcollective] mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8 [moksha] moksha-0.5.0-5.fc15.noarch requires pyevent [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [ocaml-augeas] ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0 [openvrml] libopenvrml-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires java-1.6.0-openjdk(x86-64) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-xembed-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-xembed-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit)
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 05/09/2012 03:07 PM, Jaroslav Reznik wrote: I know I've said this before, but: we should break the CD size barrier precisely so people can't burn things to CDs. If you must burn to optical media, do yourself a favor and burn a DVD, the reduced seek time is entirely worth it. I'd like to break CD limit too but we should not forgot there are users for which CD is top technology from dreams and we have a lot of these users among some countries... For me personally CD is history, even DVD, same 1 GB flash drive. We can afford it. But some people can't and are our users thanks to the ability to get a cheap OS, that can run on cheap HW and is still modern. The question is - how many people will be affected? Or should we provide some fallback option - stripped down CD media size image? And make the bigger one primary one? R. I like the idea of a separate stripped down live CD image. But it doesn't have to be too stripped down. What if we made the LXDE and/or Xfce spin's CD size, while the Gnome and KDE live images would be DVD size. *braces for the Gnome is our default desktop replies* Troy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Module-Package-0.30.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Package: 189b1f4a93999088e54d87bc735abddb Module-Package-0.30.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
TnL
I recently updated Io-language to the current release. Finally. Anyway, TnL, which requires it, had been unable to run, at least for me, and now I can't even get it to build. So unless someone else wants to take a crack at it and fix it up, I'm going to retire it in a few days. I'll be happy to provide everything I've got to interested parties, but I can't spend any more time on it. -J -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2012-05-11 @ 17:00 UTC - F17 Final Blocker Bug Review #5
# F17 Final Blocker Review meeting #5 # Date: 2012-05-11 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net The next review meeting will be on Friday, 2012-05-11. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at: https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting Tim signature.asc Description: PGP signature ___ 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: TnL
Hi, On 05/10/2012 03:26 PM, Jon Ciesla wrote: I recently updated Io-language to the current release. Finally. Anyway, TnL, which requires it, had been unable to run, at least for me, and now I can't even get it to build. So unless someone else wants to take a crack at it and fix it up, I'm going to retire it in a few days. I'll be happy to provide everything I've got to interested parties, but I can't spend any more time on it. As the guy who originally packages TnL I say just drop it, it is pretty much an unfinished game, and thus not very interesting. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Wed, 2012-05-09 at 18:00 -0400, Jon Masters wrote: Putting that another way, if we carried eglibc in Fedora, there would be cries and shouts if a large number of packages started requiring it because we have folks that maintain GLIBC. I don't believe this is entirely accurate, since glibc appears to be making moves to get eglibc merged. I feel LLVM is a similar piece of critical technology that we should not need for critpath. Honestly the biggest question I have about llvm maintenance is whether we should allow it to self-host under clang or whether we must build it with gcc. Upstream llvm typically self-hosts, and there are known bugs where clang-built-llvm works but gcc-built-llvm is crashy. We should at least make it easy to build llvm either way for comparison. I'm happy to keep patching up llvm as I hit issues in it, of course. It's something I'm stuck with for RHEL in the future anyway. I'm not likely to have the resources to investigate issues that don't affect Mesa, but as long as everybody who needs llvm can commit to that level of self-interest we should be fine. - ajax 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: Proposed F18 feature: MiniDebugInfo
On Thu, 2012-05-10 at 12:08 +0200, Kevin Kofler wrote: drago01 wrote: Not really, you are restricting yourself by the artificial CD size limit. You don't have to use the full size of whatever bigger medium you choose (DVD, 1 or 2GB stick) but you are currently providing a poorer user experience because you insist on a medium from the last century. If every live image gets larger, that will also negatively affect the nice Multi Desktop Live DVDs the Ambassadors are now mass-producing. Those contain all our live CDs (all desktops in both 32-bit and 64-bit versions, where the bitness is autodetected at boot, but can be manually overridden) on one DVD, which is a great thing to hand out at events. I am unable to find any ISOs of that media. It appears this is somewhat intentional: http://lists.fedoraproject.org/pipermail/devel/2011-June/152520.html Therefore I have difficulty evaluating just how much impact this would be. Do you have a link to the recipe for building such an image? I suspect the incremental cost of each additional desktop environment would be successively lower, but without data... - ajax 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: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On Thu, 2012-05-10 at 09:16 +0200, Kevin Kofler wrote: Adam Jackson wrote: Even if all of your objections are true, and who knows, they might be: we already do provide alternatives. The Live media is not the only install media. The other alternatives are either already DVDs or netinstall CDs which require a fast Internet connection (which people who don't even have a DVD drive are unlikely to have). So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. Do we think that's a statistically significant number of people, or are we just arguing? - ajax 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: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On Thu, May 10, 2012 at 4:00 PM, Adam Jackson a...@redhat.com wrote: On Thu, 2012-05-10 at 09:16 +0200, Kevin Kofler wrote: Adam Jackson wrote: Even if all of your objections are true, and who knows, they might be: we already do provide alternatives. The Live media is not the only install media. The other alternatives are either already DVDs or netinstall CDs which require a fast Internet connection (which people who don't even have a DVD drive are unlikely to have). So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. Do we think that's a statistically significant number of people, or are we just arguing? Would be interesting to get some input from lower-income countries. Ambassadors from those countries could perhaps tell us about the hardware which is most common. Johannes - ajax -- 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
File POE-Component-Client-Ping-1.171.tar.gz uploaded to lookaside cache by remi
A file has been added to the lookaside cache for perl-POE-Component-Client-Ping: 0ee6da4e01aa08479497a4f484a0b028 POE-Component-Client-Ping-1.171.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-Client-Ping] new Package (review #812586)
commit 7bf70955bb6c6a22c4623af836a16683dcea8337
Author: remi fed...@famillecollet.com
Date: Thu May 10 17:22:11 2012 +0200
new Package (review #812586)
.gitignore |1 +
perl-POE-Component-Client-Ping.spec | 67 +++
sources |1 +
3 files changed, 69 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..6174790 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/POE-Component-Client-Ping-1.171.tar.gz
diff --git a/perl-POE-Component-Client-Ping.spec
b/perl-POE-Component-Client-Ping.spec
new file mode 100644
index 000..a5511d3
--- /dev/null
+++ b/perl-POE-Component-Client-Ping.spec
@@ -0,0 +1,67 @@
+Name: perl-POE-Component-Client-Ping
+Version:1.171
+Release:2%{?dist}
+Summary:Non-blocking ICMP ping client
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/POE-Component-Client-Ping/
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RC/RCAPUTO/POE-Component-Client-Ping-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(POE) = 1.007
+BuildRequires: perl(Time::HiRes) = 1.2
+BuildRequires: perl(Exporter)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Socket)
+BuildRequires: perl(POE::Session)
+BuildRequires: perl(Test::More)
+
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(POE) = 1.007
+
+%{?perl_default_filter}
+
+
+%description
+POE::Component::Client::Ping is non-blocking ICMP ping client. It lets
+several other sessions ping through it in parallel, and it lets them
+continue doing other things while they wait for responses.
+
+%prep
+%setup -q -n POE-Component-Client-Ping-%{version}
+
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+
+%install
+rm -rf %{buildroot}
+
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} %{buildroot}/*
+
+
+%check
+make test
+
+
+%files
+%doc CHANGES README
+%{perl_vendorlib}/POE
+%{_mandir}/man3/*
+
+
+%changelog
+* Mon May 07 2012 Remi Collet r...@fedoraproject.org - 1.171-2
+- changes from review (#812586)
+- clean spec of EL-5 stuff (package don't build)
+
+* Sun Apr 15 2012 Remi Collet r...@fedoraproject.org - 1.171-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..290144c 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+0ee6da4e01aa08479497a4f484a0b028 POE-Component-Client-Ping-1.171.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-POE-Component-Client-Ping/f17] new Package (review #812586)
Summary of changes: 7bf7095... new Package (review #812586) (*) (*) 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
rawhide report: 20120510 changes
Compose started at Thu May 10 08:15:03 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [389-adminutil] 389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48 389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [TnL] TnL-07-19.fc18.x86_64 requires libiovmall.so.2()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [apron] ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpzf) = 0:880ed9a6a6facad4d714366014c29da3 ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpz) = 0:51fb98965622d5a322043e34aeea752c ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpqf) = 0:680f8e9f19b441bd35843ade8217a6de ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpq) = 0:ce2070543078d81083b576242a3130f2 ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpfrf) = 0:7f546e69251f5cf0a1cd3dd4a1e761b5 ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpfr) = 0:a2c8600dc093d24982e074326c5d8a06 ocaml-apron-0.9.10-5.fc17.i686 requires ocaml(Mpf) = 0:5e2e3d3ee8c86bb35a32e59abf2e9454 ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpzf) = 0:880ed9a6a6facad4d714366014c29da3 ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpz) = 0:51fb98965622d5a322043e34aeea752c ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpqf) = 0:680f8e9f19b441bd35843ade8217a6de ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpq) = 0:ce2070543078d81083b576242a3130f2 ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpfrf) = 0:7f546e69251f5cf0a1cd3dd4a1e761b5 ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpfr) = 0:a2c8600dc093d24982e074326c5d8a06 ocaml-apron-0.9.10-5.fc17.x86_64 requires ocaml(Mpf) = 0:5e2e3d3ee8c86bb35a32e59abf2e9454 [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [bibletime] bibletime-2.9.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit) bibletime-2.9.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit) [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [couchdb] couchdb-1.1.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit) couchdb-1.1.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit) couchdb-1.1.1-1.fc18.x86_64 requires libicudata.so.48()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc =
[perl-POE-Component-Client-Ping/f16] new Package (review #812586)
Summary of changes: 7bf7095... new Package (review #812586) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed F18 feature: MiniDebugInfo
On 05/10/2012 10:56 AM, Adam Jackson wrote: On Thu, 2012-05-10 at 12:08 +0200, Kevin Kofler wrote: drago01 wrote: Not really, you are restricting yourself by the artificial CD size limit. You don't have to use the full size of whatever bigger medium you choose (DVD, 1 or 2GB stick) but you are currently providing a poorer user experience because you insist on a medium from the last century. If every live image gets larger, that will also negatively affect the nice Multi Desktop Live DVDs the Ambassadors are now mass-producing. Those contain all our live CDs (all desktops in both 32-bit and 64-bit versions, where the bitness is autodetected at boot, but can be manually overridden) on one DVD, which is a great thing to hand out at events. I am unable to find any ISOs of that media. It appears this is somewhat intentional: http://lists.fedoraproject.org/pipermail/devel/2011-June/152520.html Therefore I have difficulty evaluating just how much impact this would be. Do you have a link to the recipe for building such an image? I suspect the incremental cost of each additional desktop environment would be successively lower, but without data... http://fedoraproject.org/wiki/Multi_Boot_Media_SOP Caveat: I wrote the tooling there. It does use the the generated Desktop Live ISOs as a base for making the large super ISO. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-POE-Component-Client-Ping/el6] new Package (review #812586)
Summary of changes: 7bf7095... new Package (review #812586) (*) (*) 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
meaning of i386?
Hi, I'm wondering about the meaning of the arch i386. Is it just a label, or are i386 packages still compiled to only use instructions that a 386 had? And if the latter, how come? Thanks, -Matyas Selmeci smime.p7s Description: S/MIME Cryptographic Signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On May 10, 2012, at 9:00 AM, Adam Jackson wrote: So the set of people we'd be inconveniencing is exactly the set of people with no bandwidth and the inability to boot from anything larger than a CD. Do we think that's a statistically significant number of people, or are we just arguing? Isn't it also true the Live CD is English only? English + ancient hardware + middle of nowhere. Quite honestly, this sounds like rural America (we have piss poor bandwidth in this country). Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: meaning of i386?
On Thu, 10 May 2012 11:44:44 -0500 Matyas Selmeci mat...@cs.wisc.edu wrote: Hi, I'm wondering about the meaning of the arch i386. Is it just a label, or are i386 packages still compiled to only use instructions that a 386 had? And if the latter, how come? In any place I can think of you seeing this in current Fedora, it means 32 bit. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: meaning of i386?
On 05/10/2012 12:51 PM, Kevin Fenzi wrote: On Thu, 10 May 2012 11:44:44 -0500 Matyas Selmeci mat...@cs.wisc.edu wrote: Hi, I'm wondering about the meaning of the arch i386. Is it just a label, or are i386 packages still compiled to only use instructions that a 386 had? And if the latter, how come? In any place I can think of you seeing this in current Fedora, it means 32 bit. Also, from an rpm target sense, it means optimized to i386 only instructions, which is why you will see our current Fedora RPMs say foo*.i686.rpm. hth, ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. I could log in and got the fallback shell, but it all worked sufficiently well. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Thu, 2012-05-10 at 13:40 -0400, DJ Delorie wrote: Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. I could log in and got the fallback shell, but it all worked sufficiently well. Yes, but fallback mode doesn't hit the llvm renderer path. So since the question was does anyone have llvmpipe working on arm, the answer is no. - ajax 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: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/10/2012 04:56 AM, David Airlie wrote: - Original Message - From: Jon Masters j...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Cc: Michel Alexandre Salim sali...@fedoraproject.org Sent: Wednesday, 9 May, 2012 10:57:30 PM Subject: Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers On 05/06/2012 02:29 AM, Michel Alexandre Salim wrote: LLVM is becoming an increasingly integral part of our distribution (with mesa now using it to build the LLVMpipe renderer, for example) that I don't really feel comfortable maintaining it mostly by myself. Thanks for the private email about ARM stuff. I've just kicked off another scratch build for ARM LLVM that might fix our outstanding problems. I'm ok - vaguely - in being a co-maintainer on ARM if there is nobody else on our end who can represent ARM (as it seems). I started going through some of its design over the weekend, in my copious non-existent spare time to try to understand the ARM bits. More broadly though, I feel that GCC is well represented in terms of engineering knowledge but I'm *concerned* that we run the risk of growing a dependence on LLVM that is more critical than the LLVMpipe stuff. Before we can blink, we might need LLVM for building lots of other fundamental stuff. I am wondering if as a distribution we ought to have an official FESCo-debated position on LLVM use? I do not think Fedora has the resources to maintain two critical toolchain pieces. I do think LLVM is useful, etc. BUT its growing use is concerning. Don't confuse llvm and clang, llvm has no equivalent in gcc world, clang is a C compiler like gcc that uses llvm tech. Right so I wasn't confusing these :) However, we package both together and for ease of discussion many folks are going to think of it as a gcc alternative (aside from the specific gfx situations you and ajax have). My main concern was potential for growing use beyond that. I made an analogy about glibc to which I accept ajax's response that they're trying to reconcile with eglibc, but it's more the general concept I was getting at. Let me avoid a specific example because someone will find a way to find a hole in it :) Instead, my stance is we want to be very careful about unsupportable use of LLVM. I've filed a ticket with FESCo so hopefully there can be some debate as to acceptable use :) It probably makes sense that one of myself, ajax or glisse help out packaging llvm, but we aren't the most reliable people in terms of spare time to commit. Right. You guys have various incentives to care about specific use of LLVM itself so I'm sure it will always be supported to some level, but for the other piece - clang+LLVM, etc. - to grow further use in the distro (in displacement of gcc) I feel we'd need to have actual RH staff to support it that I don't think we have any plans to have. So I want to cut this off at the pass before we blink and we have a problem. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Please add GNU id-utils to Fedora
It would be great if GNU id-utils could be included in future Fedora releases. id-utils is a long-standing GNU package that creates a database of program identifiers, then allows queries from the command line or from an editor. Its primary virtue is speed. Think of it as an optimized grep which goes fast because the database tells it exactly which files to search. It really shines on very large source-code trees, giving instant results where grep would get bogged-down in tons of extra I/O on files that don't contain hits. id-utils also benefits from already having Jim Meyering as its maintainer. Minor conflict: the name of one of id-utils main commands lid is also the same as an existing command, though installed in a different place. id-utils has /usr/bin/lid, while libuser has /usr/sbin/lid. This conflict is exceedingly minor since /usr/sbin/lid is only usable by root. Ordinary users who try it get this: $ lid foo Error initializing libuser: could not open configuration file `/etc/default/useradd': Permission denied. If there is a strict prohibition against such name conflicts, then I suggest that libuser should change lid to lugid. I speculate that the admin users of libuser are far fewer than potential general user base of id-utils, which is a program-development tool. Greg -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Please add GNU id-utils to Fedora
On Thu, May 10, 2012 at 9:49 PM, Greg McGary greg.mcg...@gmail.com wrote: Minor conflict: the name of one of id-utils main commands lid is also the same as an existing command, though installed in a different place. id-utils has /usr/bin/lid, while libuser has /usr/sbin/lid. Yeah, that's come up before. There's no great solution I'm afraid, one or the other will have to change - and the only data I've seen is debian's popcon, which indicated that libuser is used more widely. This conflict is exceedingly minor since /usr/sbin/lid is only usable by root. Ordinary users who try it get this: $ lid foo Error initializing libuser: could not open configuration file `/etc/default/useradd': Permission denied. Ordinary users can set up a different configuration to run unprivileged (in particular, to manage a LDAP user database). Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Apr 29, 2012, at 6:20 AM, Matthew Garrett wrote: On Sat, Apr 28, 2012 at 01:53:19PM -0600, Chris Murphy wrote: New problem is that the successfully installed system (from LiveCD ISO burned to DVD-RW media), upon reboot, does not eject the disc, rather it boots from it not the HDD. When I reboot with option key at the startup chime, I'm presented with six icons, none of which are Fedora. If I boot Mac OS and go to System Preferences Startup Disk, I have only a Mac OS option. #816288 ETA? I get the same results whether the installation is based on Live Desktop or DVD based installs. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
Is this a bug? If so I'll file it. When performing Replace Existing installation types, the 200MB HFS+ partition used for /boot/efi is not replaced. Instead, a new one is created each time. So if I perform five (5) Replace Existing installation types after the first Fedora install, I end up with six (6) of these 200MB HFS+ partitions. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New libtiff version in rawhide, requires dependent packages rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/06/2012 06:10 PM, Tom Lane wrote: fab gipfel fab vifir Done Kind regard, Fabian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+sLTEACgkQ4jzS3TakOX826ACeMxzJVg/jeuQ9VlqHTmbxjS4E W5QAoIqLhoeWR824gn/yqk5R6/Ndb83Q =g77V -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F18 feature: MiniDebugInfo
Adam Jackson wrote: Therefore I have difficulty evaluating just how much impact this would be. Do you have a link to the recipe for building such an image? I suspect the incremental cost of each additional desktop environment would be successively lower, but without data... The DVD is composed by glueing together the independent live images plus a boot menu, so no, the cost will not be lower for each additional desktop environment, the size is exactly the sum of the sizes of all the CD ISOs (plus a negligible overhead). Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
Chris Murphy wrote: Isn't it also true the Live CD is English only? Most of the CDs carry translations, the KDE one does not though, due to how KDE translations work (they sit in huge kde-l10n-* packages). The idea is that you install from the live CD and then you install the translation for your language(s) only. I have no need for every single kde- l10n-* langpack shipped by upstream. Hardly anybody does. Most people need only one or two languages. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On Wed, May 9, 2012 at 5:22 PM, Jaroslav Reznik wrote: - Original Message - On Wed, 2012-05-09 at 16:07 -0400, Jaroslav Reznik wrote: I know I've said this before, but: we should break the CD size barrier precisely so people can't burn things to CDs. If you must burn to optical media, do yourself a favor and burn a DVD, the reduced seek time is entirely worth it. I'd like to break CD limit too but we should not forgot there are users for which CD is top technology from dreams and we have a lot of these users among some countries... For me personally CD is history, even DVD, same 1 GB flash drive. We can afford it. But some people can't and are our users thanks to the ability to get a cheap OS, that can run on cheap HW and is still modern. The question is - how many people will be affected? Or should we provide some fallback option - stripped down CD media size image? And make the bigger one primary one? Even if all of your objections are true, and who knows, they might be: we already do provide alternatives. The Live media is not the only install media. Yep, it's not the only way, we even have our bigger offering already. And yeah, let's break CD rule but first - let ask if it still apply or not. Maybe it's my imagination and 3rd world is not anymore interested in this :) For example to Africa, we even do not ship CDs but DVDs - so at least, most people have a DVD-ROM drive :) The reason is - network bandwidth and Installation DVD fits more packages... An alternative would be to ship a live DVD, right? How hard is it to create a live DVD? Why do we not leave the decision of choosing between a live CD and a live DVD as the live image, to the spin maintainers? Even better, (hypothetically) a spin can choose to have both a live CD and a live DVD. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: meaning of i386?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 May 2012 11:44:44 -0500 Matyas Selmeci mat...@cs.wisc.edu wrote: Hi, I'm wondering about the meaning of the arch i386. Is it just a label, or are i386 packages still compiled to only use instructions that a 386 had? And if the latter, how come? Thanks, -Matyas Selmeci 32 bit x86 use i386 as the basearch in yum, its what $baseach in the mirrorlists resolves to all it means today in fedora land is 32 bit x86. Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAk+seAQACgkQkSxm47BaWff7CACgq/ZLMPxO00t7ZMO2aJpyabhL rrwAn1Ppclf9tkAQ0GtjHa+esgbI5rya =SCu9 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Thu, 2012-05-10 at 13:40 -0400, DJ Delorie wrote: Is this close enough? http://www.delorie.com/arm/f15-gnome-on-olpc.jpg That's GDM, and so useless unto the purpose. It's not accelerated. I could log in and got the fallback shell, but it all worked sufficiently well. Yes. But the context of the initial question was to find out if we actually have accelerated drivers on ARM. If anyone had seen ARM running the Shell, that would be an excellent indication that we do. Seeing ARM running fallback mode, though, indicates absolutely nothing except that it's capable of rendering graphics. :) -- 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: [Test-Announce] 2012-05-11 @ 17:00 UTC - F17 Final Blocker Bug Review #5
On Thu, 2012-05-10 at 07:33 -0600, Tim Flink wrote: # F17 Final Blocker Review meeting #5 # Date: 2012-05-11 # Time: 17:00 UTC [1] (13:00 EDT, 10:00 PDT) # Location: #fedora-bugzappers on irc.freenode.net The next review meeting will be on Friday, 2012-05-11. We'll be running through the beta blockers and nice-to-haves. An updated list of blocker bugs is available at: https://fedoraproject.org/wiki/Current_Release_Blockers. We'll be reviewing the bugs to determine ... 1. Whether they meet the final release criteria [1] and should stay on the list 2. Whether they are getting the attention they need [1] http://fedoraproject.org/wiki/Fedora_17_Final_Release_Criteria For guidance on Blocker and Nice-to-have (NTH) bugs, please refer to - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_nth_bug_process For the blocker review meeting protocol, see - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting I just wanted to make a special plea for people to take a look through the list of proposed blockers and make an effort to turn up to the meeting if they find themselves forming a strong opinion on any of the bugs. There's a couple which I suspect might turn out to be quite controversial, especially: http://bugzilla.redhat.com/show_bug.cgi?id=801650 http://bugzilla.redhat.com/show_bug.cgi?id=819492 I certainly wouldn't want there to be any perception that big decisions are being made quietly, so _please_, take a look through the proposed blocker list, and if you see something you want to have a voice in, come along to the meeting. Thanks all. -- 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
Fedora 17: Heads up for folks using xrdp with custom resolutions
Just finished fixing an upgrade of F16 to F17, where I have xrdp running under a custom resolution (i.e. the one that no known monitor would normally use). It seems that this somehow confused Gnome (or maybe gnome confused Xvnc, or xrdp or whatever) in F17, so it would basically disconnect Xvnc (which runs underneath xrdp) every time a connection would get established. I fixed this by starting Xvnc directly, connecting with VNC viewer and then applying the custom resolution (which actually did appear on the list of available resolutions) under System Settings, Displays. I even tried creating a brand new user account for this, but it would fail in exactly the same way (so it's not some old settings left over from before the upgrade). I don't really know which component caused this behaviour, ergo the general e-mail to the dev list. Maybe something to do with RandR... No idea. -- Bojan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On Thu, 2012-05-10 at 15:02 -0600, Chris Murphy wrote: Is this a bug? If so I'll file it. When performing Replace Existing installation types, the 200MB HFS+ partition used for /boot/efi is not replaced. Instead, a new one is created each time. So if I perform five (5) Replace Existing installation types after the first Fedora install, I end up with six (6) of these 200MB HFS+ partitions. I'd say almost certainly yes. AIUI on any EFI system there's only ever a reason to have _one_ EFI system partition. -- 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: How can we make F17 be able to boot on Macs (with or without reFit)
On May 10, 2012, at 8:56 PM, Adam Williamson wrote: I'd say almost certainly yes. AIUI on any EFI system there's only ever a reason to have _one_ EFI system partition. mactel-boot in effect creates an HFS+ /boot/efi partition, and does not use the existing FAT32 EFI System partition. So there are already two for Macs. But I'll take it to mean that anaconda should be able to identify and reuse a pre-existing HFS+ /boot/efi instead of creating another one. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How can we make F17 be able to boot on Macs (with or without reFit)
On 05/10/2012 09:34 PM, Chris Murphy wrote: On May 10, 2012, at 8:56 PM, Adam Williamson wrote: I'd say almost certainly yes. AIUI on any EFI system there's only ever a reason to have _one_ EFI system partition. mactel-boot in effect creates an HFS+ /boot/efi partition, and does not use the existing FAT32 EFI System partition. So there are already two for Macs. But I'll take it to mean that anaconda should be able to identify and reuse a pre-existing HFS+ /boot/efi instead of creating another one. Anaconda claims that the natural sharing of EFI System Partition across multiple OS is not supported, neither for Install nor for Update: EFI install from DVD forgets previous EFI boot https://bugzilla.redhat.com/show_bug.cgi?id=809963#c7 As far as sharing the same /boot/efi directory between installs, we don't support that -- a new copy of the grub.efi binary is written as well as a new grub.conf. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File Module-Manifest-Skip-0.16.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Manifest-Skip: 465ac6f9ad01d9042d1b87b6c2440f6f Module-Manifest-Skip-0.16.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-Module-Manifest-Skip] Import
commit 25bd2d937aa51c5bd6d129b2bc2d74568bee016f
Author: Petr Písař ppi...@redhat.com
Date: Thu May 10 08:07:31 2012 +0200
Import
.gitignore |1 +
perl-Module-Manifest-Skip.spec | 61
sources|1 +
3 files changed, 63 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..1d55255 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Module-Manifest-Skip-0.16.tar.gz
diff --git a/perl-Module-Manifest-Skip.spec b/perl-Module-Manifest-Skip.spec
new file mode 100644
index 000..b4c68e8
--- /dev/null
+++ b/perl-Module-Manifest-Skip.spec
@@ -0,0 +1,61 @@
+Name: perl-Module-Manifest-Skip
+Version:0.16
+Release:1%{?dist}
+Summary:MANIFEST.SKIP Manangement for Modules
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Module-Manifest-Skip/
+Source0:
http://www.cpan.org/authors/id/I/IN/INGY/Module-Manifest-Skip-%{version}.tar.gz
+BuildArch: noarch
+# Bundled Module::Install does not more than EU::MM and few perl-only modules
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
+BuildRequires: perl(File::ShareDir)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(Moo) = 0.009008
+# Tests:
+BuildRequires: perl(base)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(File::ShareDir)
+Requires: perl(File::Spec)
+
+%description
+CPAN module authors use a MANIFEST.SKIP file to exclude certain well known
+files from getting put into a generated MANIFEST file, which would cause them
+to go into the final distribution package.
+
+The packaging tools try to automatically skip things for you, but if you add
+one of your own entries, you have to add all the common ones yourself. This
+module attempts to make all of this boring process as simple and reliable as
+possible.
+
+
+%prep
+%setup -q -n Module-Manifest-Skip-%{version}
+# XXX: Do not unbundle build-time modules to break dependency cycle on
+# Module::Package and because upstream uses old 'name' attribute.
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Apr 23 2012 Petr Pisar ppi...@redhat.com 0.16-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..7de789b 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+465ac6f9ad01d9042d1b87b6c2440f6f Module-Manifest-Skip-0.16.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
File multidimensional-0.010.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-multidimensional: 17d5ddea428a0ac026f4baa14ff60f24 multidimensional-0.010.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-multidimensional] initial import (rhbz#810937)
commit 994c9f19969c83f882d97372e3434c2972c2b55a
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 10 05:08:04 2012 -0600
initial import (rhbz#810937)
.gitignore|1 +
no-Lexical-SealRequireHints.patch | 11 +++
perl-multidimensional.spec| 61 +
sources |1 +
4 files changed, 74 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..6bf1cc3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/multidimensional-0.010.tar.gz
diff --git a/no-Lexical-SealRequireHints.patch
b/no-Lexical-SealRequireHints.patch
new file mode 100644
index 000..fee8012
--- /dev/null
+++ b/no-Lexical-SealRequireHints.patch
@@ -0,0 +1,11 @@
+diff -up multidimensional-0.010/lib/multidimensional.pm.orig
multidimensional-0.010/lib/multidimensional.pm
+--- multidimensional-0.010/lib/multidimensional.pm.orig2012-01-27
05:34:41.0 -0700
multidimensional-0.010/lib/multidimensional.pm 2012-04-09
10:34:54.0 -0600
+@@ -8,7 +8,6 @@ package multidimensional;
+ use strict;
+ use warnings;
+
+-use Lexical::SealRequireHints 0.005;
+ use B::Hooks::OP::Check 0.19;
+ use XSLoader;
+
diff --git a/perl-multidimensional.spec b/perl-multidimensional.spec
new file mode 100644
index 000..273b22a
--- /dev/null
+++ b/perl-multidimensional.spec
@@ -0,0 +1,61 @@
+Name: perl-multidimensional
+Version:0.010
+Release:1%{?dist}
+Summary:Disables multidimensional array emulation
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/multidimensional/
+Source0:
http://www.cpan.org/authors/id/I/IL/ILMARI/multidimensional-%{version}.tar.gz
+# Lexical::SealRequireHints is only necessary for perl 5.12
+Patch0: no-Lexical-SealRequireHints.patch
+BuildRequires: perl = 0:5.008
+BuildRequires: perl(B::Hooks::OP::Check) = 0.19
+BuildRequires: perl(ExtUtils::Depends)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(lib)
+BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(XSLoader)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+Perl's multidimensional array emulation stems from the days before the language
+had references, but these days it mostly serves to bite you when you typo a
+hash slice by using the $ sigil instead of @.
+
+This module lexically makes using multidimensional array emulation a fatal
error
+at compile time.
+
+%prep
+%setup -q -n multidimensional-%{version}
+%patch0 -p1
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+RELEASE_TESTING=1 make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/multidimensional*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Apr 09 2012 Iain Arnell iarn...@gmail.com 0.010-1
+- Specfile autogenerated by cpanspec 1.79.
+- remove Lexical::SealRequireHints dependency
diff --git a/sources b/sources
index e69de29..5e628f3 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+17d5ddea428a0ac026f4baa14ff60f24 multidimensional-0.010.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-multidimensional] drop unnecessary perl buildrequire
commit bed0acbb98a65dfd5af015e749f2ad58dde331f7
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 10 05:08:57 2012 -0600
drop unnecessary perl buildrequire
perl-multidimensional.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-multidimensional.spec b/perl-multidimensional.spec
index 273b22a..7346404 100644
--- a/perl-multidimensional.spec
+++ b/perl-multidimensional.spec
@@ -1,6 +1,6 @@
Name: perl-multidimensional
Version:0.010
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Disables multidimensional array emulation
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,7 +8,6 @@ URL:http://search.cpan.org/dist/multidimensional/
Source0:
http://www.cpan.org/authors/id/I/IL/ILMARI/multidimensional-%{version}.tar.gz
# Lexical::SealRequireHints is only necessary for perl 5.12
Patch0: no-Lexical-SealRequireHints.patch
-BuildRequires: perl = 0:5.008
BuildRequires: perl(B::Hooks::OP::Check) = 0.19
BuildRequires: perl(ExtUtils::Depends)
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -56,6 +55,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Thu May 10 2012 Iain Arnell iarn...@gmail.com 0.010-2
+- drop unnecessary perl buildrequire
+
* Mon Apr 09 2012 Iain Arnell iarn...@gmail.com 0.010-1
- Specfile autogenerated by cpanspec 1.79.
- remove Lexical::SealRequireHints dependency
--
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-multidimensional/f17] (2 commits) ...drop unnecessary perl buildrequire
Summary of changes: 994c9f1... initial import (rhbz#810937) (*) bed0acb... drop unnecessary perl buildrequire (*) (*) 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-multidimensional/f16] (2 commits) ...drop unnecessary perl buildrequire
Summary of changes: 994c9f1... initial import (rhbz#810937) (*) bed0acb... drop unnecessary perl buildrequire (*) (*) 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
File bareword-filehandles-0.003.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-bareword-filehandles: 1e0ec0e72c897b238b4f9d0eb71643a4 bareword-filehandles-0.003.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-bareword-filehandles] initial import (rhbz#810939)
commit d0fa0d8d37195fd9b84465af748b8a2ba6448ee3
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 10 05:13:20 2012 -0600
initial import (rhbz#810939)
.gitignore|1 +
no-Lexical-SealRequireHints.patch | 11 +++
perl-bareword-filehandles.spec| 57 +
sources |1 +
4 files changed, 70 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..99fc9e5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/bareword-filehandles-0.003.tar.gz
diff --git a/no-Lexical-SealRequireHints.patch
b/no-Lexical-SealRequireHints.patch
new file mode 100644
index 000..1c26b2b
--- /dev/null
+++ b/no-Lexical-SealRequireHints.patch
@@ -0,0 +1,11 @@
+diff -up bareword-filehandles-0.003/lib/bareword/filehandles.pm.orig
bareword-filehandles-0.003/lib/bareword/filehandles.pm
+--- bareword-filehandles-0.003/lib/bareword/filehandles.pm.orig
2011-03-15 07:03:09.0 -0600
bareword-filehandles-0.003/lib/bareword/filehandles.pm 2012-04-09
10:42:07.0 -0600
+@@ -8,7 +8,6 @@ BEGIN {
+ use strict;
+ use warnings;
+
+-use Lexical::SealRequireHints;
+ use B::Hooks::OP::Check;
+ use XSLoader;
+
diff --git a/perl-bareword-filehandles.spec b/perl-bareword-filehandles.spec
new file mode 100644
index 000..9ea3bee
--- /dev/null
+++ b/perl-bareword-filehandles.spec
@@ -0,0 +1,57 @@
+Name: perl-bareword-filehandles
+Version:0.003
+Release:1%{?dist}
+Summary:Disables bareword filehandles
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/bareword-filehandles/
+Source0:
http://www.cpan.org/authors/id/I/IL/ILMARI/bareword-filehandles-%{version}.tar.gz
+# Lexical::SealRequireHints is only necessary on perl 5.12
+Patch0: no-Lexical-SealRequireHints.patch
+BuildRequires: perl = 0:5.008001
+BuildRequires: perl(B::Hooks::OP::Check)
+BuildRequires: perl(ExtUtils::Depends)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Pod::Coverage::TrustPod)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(XSLoader)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This module lexically disables the use of bareword filehandles with builtin
+functions, except for the special builtin filehandles STDIN, STDOUT,
+STDERR, ARGV, ARGVOUT and DATA.
+
+%prep
+%setup -q -n bareword-filehandles-%{version}
+%patch0 -p1
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=%{optflags}
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {} \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+RELEASE_TESTING=1 make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/bareword*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Apr 09 2012 Iain Arnell iarn...@gmail.com 0.003-1
+- Specfile autogenerated by cpanspec 1.79.
+- remove Lexical::SealRequireHints dependency
diff --git a/sources b/sources
index e69de29..21d4db5 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+1e0ec0e72c897b238b4f9d0eb71643a4 bareword-filehandles-0.003.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-bareword-filehandles] drop unnecessary perl BR
commit f678094f2a8f0ecfe0b09eb660a09d0d64d120d2
Author: Iain Arnell iarn...@gmail.com
Date: Thu May 10 05:15:10 2012 -0600
drop unnecessary perl BR
perl-bareword-filehandles.spec | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
---
diff --git a/perl-bareword-filehandles.spec b/perl-bareword-filehandles.spec
index 9ea3bee..e5f4038 100644
--- a/perl-bareword-filehandles.spec
+++ b/perl-bareword-filehandles.spec
@@ -1,6 +1,6 @@
Name: perl-bareword-filehandles
Version:0.003
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Disables bareword filehandles
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,7 +8,6 @@ URL:
http://search.cpan.org/dist/bareword-filehandles/
Source0:
http://www.cpan.org/authors/id/I/IL/ILMARI/bareword-filehandles-%{version}.tar.gz
# Lexical::SealRequireHints is only necessary on perl 5.12
Patch0: no-Lexical-SealRequireHints.patch
-BuildRequires: perl = 0:5.008001
BuildRequires: perl(B::Hooks::OP::Check)
BuildRequires: perl(ExtUtils::Depends)
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -22,8 +21,8 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
%{?perl_default_filter}
%description
-This module lexically disables the use of bareword filehandles with builtin
-functions, except for the special builtin filehandles STDIN, STDOUT,
+This module lexically disables the use of bareword filehandles with built-in
+functions, except for the special built-in filehandles STDIN, STDOUT,
STDERR, ARGV, ARGVOUT and DATA.
%prep
@@ -52,6 +51,9 @@ RELEASE_TESTING=1 make test
%{_mandir}/man3/*
%changelog
+* Thu May 10 2012 Iain Arnell iarn...@gmail.com 0.003-2
+- drop unnecessary perl BR
+
* Mon Apr 09 2012 Iain Arnell iarn...@gmail.com 0.003-1
- Specfile autogenerated by cpanspec 1.79.
- remove Lexical::SealRequireHints dependency
--
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-bareword-filehandles/f17] (2 commits) ...drop unnecessary perl BR
Summary of changes: d0fa0d8... initial import (rhbz#810939) (*) f678094... drop unnecessary perl BR (*) (*) 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
File Module-Install-ManifestSkip-0.20.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Module-Install-ManifestSkip: 6fe56356e71351b88dce34aa510464eb Module-Install-ManifestSkip-0.20.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-Module-Install-ManifestSkip] Import
commit 60d8298b0c697b53665d12ab193b513ee67a1c54
Author: Petr Písař ppi...@redhat.com
Date: Thu May 10 15:06:39 2012 +0200
Import
.gitignore|1 +
perl-Module-Install-ManifestSkip.spec | 49 +
sources |1 +
3 files changed, 51 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..e12e4cc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Module-Install-ManifestSkip-0.20.tar.gz
diff --git a/perl-Module-Install-ManifestSkip.spec
b/perl-Module-Install-ManifestSkip.spec
new file mode 100644
index 000..e9e7ce9
--- /dev/null
+++ b/perl-Module-Install-ManifestSkip.spec
@@ -0,0 +1,49 @@
+Name: perl-Module-Install-ManifestSkip
+Version:0.20
+Release:1%{?dist}
+Summary:Generate a MANIFEST.SKIP file
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Module-Install-ManifestSkip/
+Source0:
http://www.cpan.org/authors/id/I/IN/INGY/Module-Install-ManifestSkip-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+# Run-time:
+BuildRequires: perl(base)
+BuildRequires: perl(Module::Manifest::Skip) = 0.10
+# Tests:
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+This module generates a MANIFEST.SKIP file for you (using
+Module::Manifest::Skip) that contains the common files that people do not
+want in their MANIFEST files. The SKIP file is generated each time that you
+(the module author) run Makefile.PL.
+
+%prep
+%setup -q -n Module-Install-ManifestSkip-%{version}
+# XXX: Keep bundled built-time modules to break dependency cycle on
+# Module::Package and because upstream uses old 'name' attribute.
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Mon Apr 23 2012 Petr Pisar ppi...@redhat.com 0.20-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..95ceaf7 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+6fe56356e71351b88dce34aa510464eb Module-Install-ManifestSkip-0.20.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-Sys-MemInfo/f17] Initial release
commit 4a86d620df70667a581aeeccb389fd62320ebbef
Author: Jan Synacek jsyna...@redhat.com
Date: Thu May 10 15:08:29 2012 +0200
Initial release
.gitignore|1 +
perl-Sys-MemInfo.spec | 47 +++
sources |1 +
3 files changed, 49 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..1e12859 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Sys-MemInfo-0.91.tar.gz
diff --git a/perl-Sys-MemInfo.spec b/perl-Sys-MemInfo.spec
new file mode 100644
index 000..de488f4
--- /dev/null
+++ b/perl-Sys-MemInfo.spec
@@ -0,0 +1,47 @@
+Name: perl-Sys-MemInfo
+Version:0.91
+Release:1%{?dist}
+Summary:Sys::MemInfo Perl module
+License:LGPLv2+
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Sys-MemInfo/
+Source0:
http://www.cpan.org/modules/by-module/Sys/Sys-MemInfo-%{version}.tar.gz
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Data::Dumper)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+Sys::MemInfo return the total amount of free and used physical memory in
+bytes in totalmem and freemem variables.
+
+%prep
+%setup -q -n Sys-MemInfo
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorarch}/auto/*
+%{perl_vendorarch}/Sys*
+%{_mandir}/man3/*
+
+%changelog
+* Fri May 04 2012 jsyna...@redhat.com 0.91-1
+- Initial release
diff --git a/sources b/sources
index e69de29..2e39002 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+d2ddda32c58114352e04ecb866de7f17 Sys-MemInfo-0.91.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
[389-devel] please review ticket #218 - Make RI Plugin work with replicated entries
https://fedorahosted.org/389/ticket/218 https://fedorahosted.org/389/attachment/ticket/218/0001-Ticket-218-Make-RI-Plugin-worked-with-replicated-upd.patch The diff is very large because I redid all the indentation in referint.c (it was a mess!) The changes to look at are in: referint_postop_init() referint_postop_del() referint_postop_modrdn() _do_modify() and repl5_plugins.c Thanks, Mark -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
