Re: MySQL and MariaDB in Fedora
On 04/14/2013 07:10 PM, Matthias Runge wrote: On 04/14/2013 06:54 PM, Jóhann B. Guðmundsson wrote: Convincing this is about doing the right thing! I your intention was to ban mysql in the distribution then it should have been banned and dropped instead of this mess that you guys have created. IMHO you cannot ban/deprecate a package from the distro, if there's still a packager/contributor to the package. Also you can not force somebody to drop a package. I'm aware of that but we can force migration upon users on upgrades while we still provide and ship that component? If users have *chosen* to install component A and we *still* provide ( maintain,package and ship ) component A, the users should be upgraded to that components latest release upon upgrade. If users have *chosen* to install component A and we *no longer* provide ( maintain,package and ship ) component A then the argument can be made that we should migrate component A to component B during release upgrades if it provides same or similar functionality ( even thou I feel it's bad policy doing so and we would be better of doing nothing as in simply not upgrade or migrate that component unless it becomes absolutely necessary ) JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MySQL and MariaDB in Fedora
Il 15/04/2013 08:19, Jóhann B. Guðmundsson ha scritto: On 04/14/2013 07:10 PM, Matthias Runge wrote: On 04/14/2013 06:54 PM, Jóhann B. Guðmundsson wrote: Convincing this is about doing the right thing! I your intention was to ban mysql in the distribution then it should have been banned and dropped instead of this mess that you guys have created. IMHO you cannot ban/deprecate a package from the distro, if there's still a packager/contributor to the package. Also you can not force somebody to drop a package. I'm aware of that but we can force migration upon users on upgrades while we still provide and ship that component? If users have *chosen* to install component A and we *still* provide ( maintain,package and ship ) component A, the users should be upgraded to that components latest release upon upgrade. If users have *chosen* to install component A and we *no longer* provide ( maintain,package and ship ) component A then the argument can be made that we should migrate component A to component B during release upgrades if it provides same or similar functionality ( even thou I feel it's bad policy doing so and we would be better of doing nothing as in simply not upgrade or migrate that component unless it becomes absolutely necessary ) JBG +1 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On 04/05/13 at 04:16pm, Jakub Jelinek wrote: On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote: I repeated the benchmarks (mentioned in the above bug report) for Firefox 20.0 running on Fedora 18 64-bit. Firefox as benchmark doesn't look like a good idea (and I'm really surprised that we don't compile it as PIE, I thought we've been doing that for years). The special thing on firefox is that it is really tiny binary ( 64K of .text) with almost no libraries linked directly (just -lc, -ldl, -lstdc++, -lpthread and their dependencies (-lm, -lgcc_s)), so indeed the relocation processing isn't very expensive (only ~ 130 relocations) before reaching main and prelink can't make it significantly faster. ... I see the problem with using Firefox as a benchmark now. So I started looking for more suitable applications to benchmark and came across Gimp. $ ldd /usr/bin/gimp-2.8 | wc -l 77 $ du -hs /usr/bin/gimp-2.8 5.8M/usr/bin/gimp-2.8 Looks good to use as a benchmark? I ran some benchmarks on various builds of Gimp. Please note that the F18 upstream build has PIE enabled. The benchmarking steps are described at https://github.com/kholia/gimp-bench My Results == ~ 39.160s == upstream my build ~ 39.750s == upstream stock build ~ 40.850s == non-PIE my build The PIE version turns out to be a bit faster. This seems weird and I can't explain it. Grant repeated the tests independently and his results are below, Grant's Results === (No PIE) [gm@localhost gimp-bench]$ time ./launch.sh batch command executed successfully real2m13.267s user1m25.577s sys 0m46.474s (PIE) [gm@localhost gimp-bench]$ time ./launch.sh batch command executed successfully real2m4.328s user1m22.506s sys 0m44.958s PIE build is faster than the non-PIE build (again!) it seems. ... These results are weird and I can't explain them. Do you have any insights on why the PIE build of Gimp is faster than the non-PIE build? -- Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote: I repeat: The proper solution is to prevent executing any machine code which is not part of the program's source code. You're simply wrong about this. It's trivial to come up with a counter-example, if you're prepared to give it a couple of minutes of thought. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote: Richard W.M. Jones wrote: I said it doesn't implement full bounds checking for every C object, and I stand by that. I doesn't cover stack objects smaller than some cut-off size, nor any objects in static data or on the heap at all. I never claimed it did. I said it prevents overwriting the return address on the stack to execute arbitrary code. That's all it ever claimed to do. What you actually said was: build ALL packages in Fedora with not only -fPIE and RELRO, but also -fstack-protector-all (which is not included in the current hardened cflags). Also get rid of prelink which reduces the effectiveness of ASLR. Then drop SELinux which becomes obsolete if the executables cannot be exploited in the first place. (It only papers over the real problem.) which I interpret to mean that after using -fstack-protector-all and removing prelink, SELinux would become obsolete because no executable can be exploited. And there is no cutoff size with -fstack-protector-all. Not true, there is still a small cutoff size and many types of object not covered -- see Steve Grubb's email. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
next pkgdb?
On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: It returns you to pkgdb to set acls and the relationships tab gives an error. I was mainly looking at it to manage permissions (right now). Packages is not meant for this And when I meant functional I meant FULLY functional, meaning I wouldn't have to touch pkdgb ever again. May I ask what is wrong with pkgdb? I'm involved in writing the next generation of pkgdb, so inputs on what it should do/look like are very welcome. Please tell me, what's wrong with pkgdb and feel free to suggest how it could be fixed. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, Apr 15, 2013 at 3:08 AM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: It returns you to pkgdb to set acls and the relationships tab gives an error. I was mainly looking at it to manage permissions (right now). Packages is not meant for this And when I meant functional I meant FULLY functional, meaning I wouldn't have to touch pkdgb ever again. May I ask what is wrong with pkgdb? I'm involved in writing the next generation of pkgdb, so inputs on what it should do/look like are very welcome. Please tell me, what's wrong with pkgdb and feel free to suggest how it could be fixed. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel 1) It's slow. 2) It's spammy. 3) Setting ACLs is cumbersome. (related to #2) Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, Apr 15, 2013 at 12:08:24 +0200, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: It returns you to pkgdb to set acls and the relationships tab gives an error. I was mainly looking at it to manage permissions (right now). Packages is not meant for this And when I meant functional I meant FULLY functional, meaning I wouldn't have to touch pkdgb ever again. May I ask what is wrong with pkgdb? I'm involved in writing the next generation of pkgdb, so inputs on what it should do/look like are very welcome. Please tell me, what's wrong with pkgdb and feel free to suggest how it could be fixed. It would be nice to be able to change acls without having to enable javascript. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Trimming (or obsoleting) %changelog?
Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, 15 Apr 2013 12:08:24 +0200 Pierre-Yves Chibon pin...@pingoured.fr wrote: On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: It returns you to pkgdb to set acls and the relationships tab gives an error. I was mainly looking at it to manage permissions (right now). Packages is not meant for this And when I meant functional I meant FULLY functional, meaning I wouldn't have to touch pkdgb ever again. May I ask what is wrong with pkgdb? I'm involved in writing the next generation of pkgdb, so inputs on what it should do/look like are very welcome. Please tell me, what's wrong with pkgdb and feel free to suggest how it could be fixed. ownership of a package by a group Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, 2013-04-15 at 12:34 +0200, Dan Horák wrote: ownership of a package by a group On Mon, 2013-04-15 at 05:29 -0500, Bruno Wolff III wrote: It would be nice to be able to change acls without having to enable javascript. On Mon, 2013-04-15 at 03:29 -0700, Dan Mashal wrote: 1) It's slow. 2) It's spammy. Thanks for the quick feed-back, I'm glad to see that these points were already on the list. Removing the ajax calls (so allowing no js) should solve the spammy problem as well. The group ownership is pretty much planned but we still need to figure out the details. We're also thinking of a Become comaintainer button that applies for you to all ACLs for the latest 2 branches (for example). In the same spirit, maybe a Watch package button that applies for the watchcommits and watchbugs ACLs. Basically, simplify the interface while still providing the more current possibilities if one wishes. Any other suggestions are welcomed of course :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130415 changes
Compose started at Mon Apr 15 08:15:47 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [diet] diet-2.8.1-5.fc19.i686 requires libxqilla.so.5 diet-2.8.1-5.fc19.x86_64 requires libxqilla.so.5()(64bit) diet-examples-2.8.1-5.fc19.x86_64 requires libxqilla.so.5()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eg] eg-1.7.5.2-1.fc20.noarch requires perl(one) eg-1.7.5.2-1.fc20.noarch requires perl(it) eg-1.7.5.2-1.fc20.noarch requires perl(an) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [kde-settings] kde-settings-kdm-19-17.fc20.1.noarch requires /lib/systemd/systemd-multi-seat-x [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [mapserver] php-mapserver-6.0.3-9.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-mapserver-6.0.3-9.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-sqlite-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-xml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-xml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) [mygui] mygui-3.2.0-4.fc20.i686
Broken dependencies: rubygem-pam
I am not sure how to fix this. The current spec file in master and f19 has the following requires: BuildRequires: ruby-devel = 1.9 Requires: ruby(abi) = 1.9 The current package is at 2.0 which should be ok. Is there an obvious change I need to make? -- bk Original Message Subject: Broken dependencies: rubygem-pam Date: Mon, 15 Apr 2013 11:49:52 + (UTC) From: build...@fedoraproject.org To: rubygem-pam-ow...@fedoraproject.org rubygem-pam has broken dependencies in the F-19 tree: On x86_64: rubygem-pam-1.5.4-14.fc19.x86_64 requires ruby(abi) = 0:1.9 On i386: rubygem-pam-1.5.4-14.fc19.i686 requires ruby(abi) = 0:1.9 Please resolve this as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-DBD-MySQL had acl change status
ppisar has set the watchcommits acl on perl-DBD-MySQL (Fedora 19) to Approved for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-DBD-MySQL -- 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
[pkgdb] perl-DBD-MySQL had acl change status
ppisar has set the watchcommits acl on perl-DBD-MySQL (Fedora 18) to Approved for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-DBD-MySQL -- 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-19 Branched report: 20130415 changes
Compose started at Mon Apr 15 09:15:16 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit) [clementine] clementine-1.1.1-1.fc19.x86_64 requires libprotobuf.so.7()(64bit) clementine-1.1.1-1.fc19.x86_64 requires libimobiledevice.so.3()(64bit) [connman] connman-1.5-4.fc19.i686 requires libxtables.so.7 connman-1.5-4.fc19.i686 requires libgnutls.so.26(GNUTLS_1_4) connman-1.5-4.fc19.i686 requires libgnutls.so.26 connman-1.5-4.fc19.x86_64 requires libxtables.so.7()(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) connman-1.5-4.fc19.x86_64 requires libgnutls.so.26()(64bit) [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [denemo] denemo-0.9.4-0.fc18.x86_64 requires libgtksourceview-3.0.so.0()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [eruby] eruby-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) eruby-libs-1.0.5-19.fc18.i686 requires ruby(abi) = 0:1.9.0 eruby-libs-1.0.5-19.fc18.i686 requires libruby.so.1.9 eruby-libs-1.0.5-19.fc18.x86_64 requires ruby(abi) = 0:1.9.0 eruby-libs-1.0.5-19.fc18.x86_64 requires libruby.so.1.9()(64bit) [fawkes] fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8(LIBJPEG_8.0) fawkes-firevision-0.5.0-5.fc19.i686 requires libjpeg.so.8 fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8(LIBJPEG_8.0)(64bit) fawkes-firevision-0.5.0-5.fc19.x86_64 requires libjpeg.so.8()(64bit) fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gearbox] gearbox-10.11-3.fc19.i686 requires libIceUtil.so.35b gearbox-10.11-3.fc19.x86_64 requires libIceUtil.so.35b()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [gnome-pie] gnome-pie-0.5.3-3.20120826git1b93e1.fc19.x86_64 requires libbamf3.so.0()(64bit) [gnomint] gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_2_8)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26(GNUTLS_1_4)(64bit) gnomint-1.2.1-5.fc18.x86_64 requires libgnutls.so.26()(64bit) [gooddata-cl] gooddata-cl-1.2.56-2.fc19.noarch requires gdata-java [gorm] gorm-1.2.18-1.fc19.i686 requires libgnustep-gui.so.0.22 gorm-1.2.18-1.fc19.x86_64 requires libgnustep-gui.so.0.22()(64bit) [kawa] 1:kawa-1.11-5.fc19.x86_64 requires servlet25 [libkolab] php-kolab-0.4.1-3.fc19.x86_64 requires php(zend-abi) = 0:20100525-x86-64 php-kolab-0.4.1-3.fc19.x86_64 requires php(api) = 0:20100412-x86-64 [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686
Re: Broken dependencies: rubygem-pam
Hi, change ruby(abi) to Requires: ruby(release) as in guidelines [1] Each Ruby package must indicate it depends on a Ruby interpreter. Use ruby(release) virtual requirement to achieve that: This is due to support both MRI and JRuby in next Fedora releases. [1] https://fedoraproject.org/wiki/Packaging:Ruby Regards Josef - Original Message - From: Bryan Kearney bkear...@redhat.com To: devel@lists.fedoraproject.org Sent: Monday, April 15, 2013 1:54:05 PM Subject: Broken dependencies: rubygem-pam I am not sure how to fix this. The current spec file in master and f19 has the following requires: BuildRequires: ruby-devel = 1.9 Requires: ruby(abi) = 1.9 The current package is at 2.0 which should be ok. Is there an obvious change I need to make? -- bk Original Message Subject: Broken dependencies: rubygem-pam Date: Mon, 15 Apr 2013 11:49:52 + (UTC) From: build...@fedoraproject.org To: rubygem-pam-ow...@fedoraproject.org rubygem-pam has broken dependencies in the F-19 tree: On x86_64: rubygem-pam-1.5.4-14.fc19.x86_64 requires ruby(abi) = 0:1.9 On i386: rubygem-pam-1.5.4-14.fc19.i686 requires ruby(abi) = 0:1.9 Please resolve this as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-File-Fetch] Revert Teach rpmlint
commit 19e7a110abbd77817d909a6e5715f48d336c91a9 Author: Petr Písař ppi...@redhat.com Date: Mon Apr 15 14:46:03 2013 +0200 Revert Teach rpmlint This reverts commit 787a690ec94d904da883b726dc88aa4098ff8056. .build-0.38-1.fc20.log| 94 -- .build-0.42-1.fc20.log| 94 -- .rpmlint |2 - File-Fetch-0.38/CHANGES | 214 --- File-Fetch-0.38/MANIFEST |9 - File-Fetch-0.38/META.json | 54 - File-Fetch-0.38/META.yml | 32 - File-Fetch-0.38/MYMETA.json | 54 - File-Fetch-0.38/MYMETA.yml| 32 - File-Fetch-0.38/Makefile | 898 --- File-Fetch-0.38/Makefile.PL | 56 - File-Fetch-0.38/README| 40 - File-Fetch-0.38/blib/lib/File/Fetch.pm| 1658 File-Fetch-0.38/blib/man3/File::Fetch.3pm | 456 -- File-Fetch-0.38/lib/File/Fetch.pm | 1658 File-Fetch-0.38/t/01_File-Fetch.t | 281 File-Fetch-0.38/t/null_subclass.t | 23 - File-Fetch-0.42/CHANGES | 222 --- File-Fetch-0.42/MANIFEST |9 - File-Fetch-0.42/META.json | 54 - File-Fetch-0.42/META.yml | 32 - File-Fetch-0.42/MYMETA.json | 54 - File-Fetch-0.42/MYMETA.yml| 32 - File-Fetch-0.42/Makefile | 898 --- File-Fetch-0.42/Makefile.PL | 56 - File-Fetch-0.42/README| 40 - File-Fetch-0.42/blib/lib/File/Fetch.pm| 1708 - File-Fetch-0.42/blib/man3/File::Fetch.3pm | 459 -- File-Fetch-0.42/lib/File/Fetch.pm | 1708 - File-Fetch-0.42/t/01_File-Fetch.t | 303 File-Fetch-0.42/t/null_subclass.t | 23 - noarch/perl-File-Fetch-0.38-1.fc20.noarch.rpm | Bin 25572 - 0 bytes noarch/perl-File-Fetch-0.42-1.fc20.noarch.rpm | Bin 25792 - 0 bytes perl-File-Fetch-0.38-1.fc20.src.rpm | Bin 23731 - 0 bytes perl-File-Fetch-0.42-1.fc20.src.rpm | Bin 24063 - 0 bytes 35 files changed, 0 insertions(+), 11253 deletions(-) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-File-Fetch] Teach rpmlint
commit b5288b83ada5420e29ddbe876420a754e1a3b9cb Author: Petr Písař ppi...@redhat.com Date: Mon Apr 15 14:46:46 2013 +0200 Teach rpmlint .rpmlint |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.rpmlint b/.rpmlint new file mode 100644 index 000..21e112e --- /dev/null +++ b/.rpmlint @@ -0,0 +1,2 @@ +from Config import * +addFilter(spelling-error .* (http|rsync)); -- 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
meswa-libs* breaks X11 fedora 19
I've a dell E6500 running F19. Did a yum upgrade from F18. All has been working great untill I tried to upgrade the following: mesa-libEGL.i686 9.1-6.fc19updates-testing mesa-libEGL.x86_64 9.1-6.fc19updates-testing mesa-libEGL-devel.x86_64 9.1-6.fc19updates-testing mesa-libGL.x86_64 9.1-6.fc19updates-testing mesa-libGL-devel.x86_649.1-6.fc19updates-testing mesa-libGLES.x86_649.1-6.fc19updates-testing mesa-libOSMesa.x86_64 9.1-6.fc19updates-testing mesa-libgbm.i686 9.1-6.fc19updates-testing mesa-libgbm.x86_64 9.1-6.fc19updates-testing mesa-libglapi.i686 9.1-6.fc19updates-testing mesa-libglapi.x86_64 9.1-6.fc19updates-testing Gnome-shell stops, reboot into a blank screen. Had to rollback and it works great. -- Brian Millett Why make history if you fail to learn from it? 'You know Vir, you have what the Earthers call a negative personality.' No I don't. 'There, you see?' -- [ Vir and Londo, Knives] -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 952179] perl-File-Fetch-0.42 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952179 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-File-Fetch-0.42-1.fc20 Resolution|--- |RAWHIDE Last Closed||2013-04-15 08:56:53 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=7Sv9ySymLla=cc_unsubscribe -- 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: Broken dependencies: rubygem-pam
Hi Bryan, If you are OK with: * making the .spef file F19+ compatible only * dropping the ruby-pam sub-package I can fix the .spec file for you. Please let me know. Vít Dne 15.4.2013 13:54, Bryan Kearney napsal(a): I am not sure how to fix this. The current spec file in master and f19 has the following requires: BuildRequires: ruby-devel = 1.9 Requires: ruby(abi) = 1.9 The current package is at 2.0 which should be ok. Is there an obvious change I need to make? -- bk Original Message Subject: Broken dependencies: rubygem-pam Date: Mon, 15 Apr 2013 11:49:52 + (UTC) From: build...@fedoraproject.org To: rubygem-pam-ow...@fedoraproject.org rubygem-pam has broken dependencies in the F-19 tree: On x86_64: rubygem-pam-1.5.4-14.fc19.x86_64 requires ruby(abi) = 0:1.9 On i386: rubygem-pam-1.5.4-14.fc19.i686 requires ruby(abi) = 0:1.9 Please resolve this as soon as possible. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. I wonder if there are legal issues involved as the %changelog also list all the person that worked on that spec file. As for all project, in case of licensing changes, you need to know all the authors that ever contributed to the project. But again, IANAL :) Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File File-Temp-0.2301.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-File-Temp: 75a8aec1916ebbe88988ce68e84ccdd7 File-Temp-0.2301.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-File-Temp] 0.2301 bump
commit 8533e181dc3025e3b18a7c043db8daf3193b8463
Author: Petr Písař ppi...@redhat.com
Date: Mon Apr 15 15:09:04 2013 +0200
0.2301 bump
.gitignore |1 +
perl-File-Temp.spec | 26 --
sources |2 +-
3 files changed, 18 insertions(+), 11 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e8e3add..1ff62e3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/File-Temp-0.23.tar.gz
+/File-Temp-0.2301.tar.gz
diff --git a/perl-File-Temp.spec b/perl-File-Temp.spec
index 2f1a4e9..61dcd7d 100644
--- a/perl-File-Temp.spec
+++ b/perl-File-Temp.spec
@@ -1,15 +1,16 @@
+%global cpan_version 0.2301
Name: perl-File-Temp
-Version:0.23
+# Keep 2-digit version to align with future versions
+Version:%(echo '%{cpan_version}' | sed 's/\(\...\)\(.\)/\1.\2/')
Release:1%{?dist}
Summary:Return name and handle of a temporary file safely
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/File-Temp/
-Source0:
http://www.cpan.org/authors/id/T/TJ/TJENNESS/File-Temp-%{version}.tar.gz
+Source0:
http://www.cpan.org/authors/id/D/DA/DAGOLDEN/File-Temp-%{cpan_version}.tar.gz
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(File::Spec) = 0.8
-BuildRequires: perl(Module::Build) = 0.36
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time:
@@ -22,6 +23,7 @@ BuildRequires: perl(Errno)
BuildRequires: perl(Exporter)
BuildRequires: perl(Fcntl) = 1.03
BuildRequires: perl(File::Path) = 2.06
+BuildRequires: perl(File::Spec) = 0.8
BuildRequires: perl(IO::Handle)
BuildRequires: perl(IO::Seekable)
BuildRequires: perl(overload)
@@ -51,26 +53,30 @@ name and the open file handle of a temporary file. The
tempdir() function
can be used to create a temporary directory.
%prep
-%setup -q -n File-Temp-%{version}
+%setup -q -n File-Temp-%{cpan_version}
chmod -x misc/benchmark.pl
%fix_shbang_line misc/benchmark.pl
%build
-perl Build.PL installdirs=vendor
-./Build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
%install
-./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
-./Build test
+make test
%files
-%doc ChangeLog misc README
+%doc Changes LICENSE misc README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Mon Apr 15 2013 Petr Pisar ppi...@redhat.com - 0.23.01-1
+- 0.2301 bump
+
* Fri Mar 22 2013 Petr Pisar ppi...@redhat.com 0.23-1
- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index 759e5b9..7f58993 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-0db571dc413db53c5bcbba41e3c3cadc File-Temp-0.23.tar.gz
+75a8aec1916ebbe88988ce68e84ccdd7 File-Temp-0.2301.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-File-Temp] Teach rpmlint
commit f1535f9e905d616a69913d335f5c250f82b38f1c Author: Petr Písař ppi...@redhat.com Date: Mon Apr 15 15:10:00 2013 +0200 Teach rpmlint .rpmlint |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.rpmlint b/.rpmlint new file mode 100644 index 000..62edac9 --- /dev/null +++ b/.rpmlint @@ -0,0 +1,2 @@ +from Config import * +addFilter(spelling-error .* (tempfile|tempdir)); -- 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: Trimming (or obsoleting) %changelog?
At the moment, my best judgment is trim anything older than one year and that's what I've been doing to my packages. Thanks for the sanity check. Richard On 15 April 2013 13:43, Rex Dieter rdie...@math.unl.edu wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. -- rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On 15 Apr 2013 14:16, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. I wonder if there are legal issues involved as the %changelog also list all the person that worked on that spec file. As for all project, in case of licensing changes, you need to know all the authors that ever contributed to the project. But again, IANAL :) I believe the spec files are by default covered under the Fedora Contributor License Agreement (the cla all contributors have to agree to in fas before contributing) and that covers any project wide license changes too I believe. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, Apr 15, 2013 at 12:55:35 +0200, Pierre-Yves Chibon pin...@pingoured.fr wrote: We're also thinking of a Become comaintainer button that applies for you to all ACLs for the latest 2 branches (for example). You'd probably want the default to be all active Fedora branches rather than the latest 2. You might have another button for all branches (which includes EPEL). People wanting other than those two groups are probably going to pick and choose, so it's probably not worth having group buttons. In the same spirit, maybe a Watch package button that applies for the watchcommits and watchbugs ACLs. You might want to have some way to handle getting combinations of access. For example if you request acl access, you really should request all of the rest by default. Commit access should get watchcommits and watchbugs by default. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
which I interpret to mean that after using -fstack-protector-all and
removing prelink, SELinux would become obsolete because no executable
can be exploited.
I would say there is a place for SE Linux even if we compiled everything with
all because FORTIFY_SOURCE coverage is not absolute. For example, about a
month ago i ran the following test:
procs=`ls /proc | grep '^[0-9]' | sort -n`
for p in $procs
do
res=`cat /proc/$p/maps 2/dev/null | awk '$2 ~ wx { print $2 }'`
if [ x$res != x ] ; then
cat /proc/$p/cmdline | awk '{ printf %-35s\t, $1 }'
printf %s\n $p
fi
done
What this does is display the programs with Writable and Executable memory.
All Fedora desktops except Mate have WX memory. (I checked KDE, Gnome,
Cinnamon, and Mate.) WX memory is dangerous because the normal exploit pattern
is:
1) Allocate executable memory
2) Copy shell code into it
3) Jump to shell code
4) Profit!
The WX memory on virtually all the desktops means Step 1 is completed. All an
attacker needs to do is copy payload to Wx memory and jump to it. SE Linux is
the last line of defence. Of course to be effective, this means that SE Linux
has to have policy around the same applications that parse untrusted media so
that when they are exploited it knows abnormal behavior.
And there is no cutoff size with -fstack-protector-all.
All really is all. There is no cutoff. (There is a cutoff for the regular stack-
protector, but we have a good default.) It does not help for heap related
objects, though. What I would prefer rather than all is the strong patch.
If you have a void function with no local variables, all will place a canary
even though one is not needed. However, strong will not and that will make
the program run a bit faster. The strong patch really represents a good
balance between speed and covering everything that matters.
And at Infiltrate 2013, one new technique for exploitation that was discussed
was pivoting the stack pointer to something like the heap where you might have
executable permissions. I think this was discussed in context to exploiting
ARM systems, but in a post PC world this will be increasingly important.
Also demonstrated at Infiltrate last week was the next kind of attack that
occurs even when you do things nearly perfect. Windows 8 has vastly improved
exploit countermeasures (there is a presentation at BlackHat 2012). For
example, it has guard pages between memory allocations, they changed heap
allocations 16K (which is the majority of all uses) to be bit mapped based
so there is no possibility heap state attacks. It also randomly assigns blocks
so that behavior is non-deterministic. Sounds hard to exploit?
It turns out there is a weakness. The medium sized allocator has predictable
behavior and its memory gets reused. What the attack demonstrated was that an
attacker can use the Feng Shui technique to cause the placement of memory
allocation of a structure holding a function pointer right beside a vulnerable
buffer so that they can modify the function pointer and then wait for it to get
used. Eric also demonstrated that he could do this in the Windows 8 kernel,
too. So, watch out for function pointers, too. :-)
-Steve
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
File XML-LibXML-2.0016.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-XML-LibXML: d3bbc3437f6b39eca5825e9d0b0c187a XML-LibXML-2.0016.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: Expanding the list of Hardened Packages
On Mon, 2013-04-15 at 09:12 +0100, Richard W.M. Jones wrote: which I interpret to mean that after using -fstack-protector-all and removing prelink, SELinux would become obsolete because no executable can be exploited. No; there are plenty of exploits which aren't due to buffer overflows. Particularly in the era of web applications; a lot of people just toss up a Django or Ruby on Rails app, but it's *so* easy in those frameworks to have a bug that allows arbitrary code execution in the context of the service. SELinux is a good match for these sorts of apps, we just don't have the management tools and documentation to make it easy for web application authors to use. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 952130] Provide perl-podlators
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 --- Comment #3 from Gianluca Sforna gia...@gmail.com --- This is weird. So it seems it took four commits to fprintd to settle on a suboptimal one :) http://pkgs.fedoraproject.org/cgit/fprintd.git/commit/?id=f40f69460a2cd7f6e09e87f9f5694499b7891cfd -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=L0dbe4Ql1Ba=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 952130] Provide perl-podlators
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 --- Comment #4 from Gianluca Sforna gia...@gmail.com --- And anyway, I can't see how adding a Provides for something which is actually provided qualifies as a new feature. Thanks anyway for the prompt reply. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=GSiZBvVLqea=cc_unsubscribe -- 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: Keeping old versions of packages
On Sun, Apr 14, 2013 at 12:31 PM, Richard Hughes hughsi...@gmail.comwrote: On 13 April 2013 23:09, Kevin Kofler kevin.kof...@chello.at wrote: Sure you can! It's a basic rule of QA that small isolated changes can be debugged much better than a huge hodgepodge of many totally unrelated changes. Not true for the majority of GNOME and KDE packages. You can't test gnome-control-center 3.9.1 without installing gnome-settings-daemon 3.9.1 as well. A desktop environment should be a comparatively small subset of the overall universe of packages (in particular, when compared to the applications written for that desktop environment), so optimizing the distribution update system for desktop environment updates doesn't make that much sense. Desktop environment updates can be published as a group with the current model already. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, Apr 15, 2013 at 12:08:24PM +0200, Pierre-Yves Chibon wrote: Please tell me, what's wrong with pkgdb and feel free to suggest how it could be fixed. I don't know if pkgdb covers this bit of UI: https://admin.fedoraproject.org/pkgdb but it'd be nice if the Applications button was removed or at least was not the default (the default and possibly the only button should be Packages). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On Mon, Apr 15, 2013 at 11:30:20AM +0100, Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. I believe we've had this discussion before but I don't have a link handy. I think that people said they liked historical information to know when a bug, feature, or fix might have entered into a package (where people being end users, people who are primarily users, not packagers, even packagers who are looking at packagest hat they don't own). However, people did seem to agree that there was a cutoff somewhere in the past where they no longer cared. If I remember, I tend to trim off changelog entries that are more than two years old once a year for packages that I own. Two years is twice the length of a Fedora EOL cycle and since it grows to three years during the interim, that seems a reasonable distance in the past for people trying to get a quick glimpse of when something might have changed. -Toshio pgpjRhllg5b01.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi a.bad...@gmail.comwrote: If I remember, I tend to trim off changelog entries that are more than two years old once a year for packages that I own. Two years is twice the length of a Fedora EOL cycle and since it grows to three years during the interim, that seems a reasonable distance in the past for people trying to get a quick glimpse of when something might have changed. Would it be difficult to have some part of the build process check to see if there's dates older than 2-3 years and report it somewhere? Preferably somewhere where it will get noticed, but not be obtrusive. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
Dne 15.4.2013 18:03, Richard Shaw napsal(a): On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi a.bad...@gmail.com mailto:a.bad...@gmail.com wrote: If I remember, I tend to trim off changelog entries that are more than two years old once a year for packages that I own. Two years is twice the length of a Fedora EOL cycle and since it grows to three years during the interim, that seems a reasonable distance in the past for people trying to get a quick glimpse of when something might have changed. Would it be difficult to have some part of the build process check to see if there's dates older than 2-3 years and report it somewhere? Preferably somewhere where it will get noticed, but not be obtrusive. Not sure if the age of entry is the only metrics which should be used. What if there was no change in last 3 years? Then we will have just one changelog entry? Just thinking loud ... Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
On Mon, 15 Apr 2013 11:03:34 -0500 Richard Shaw hobbes1...@gmail.com wrote: On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi a.bad...@gmail.comwrote: If I remember, I tend to trim off changelog entries that are more than two years old once a year for packages that I own. Two years is twice the length of a Fedora EOL cycle and since it grows to three years during the interim, that seems a reasonable distance in the past for people trying to get a quick glimpse of when something might have changed. Would it be difficult to have some part of the build process check to see if there's dates older than 2-3 years and report it somewhere? Preferably somewhere where it will get noticed, but not be obtrusive. createrepo truncates the changelogs in the repodata to some limit - I forget what it is set to in koji. Istr that something like that was made an option in rpm, too. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.netwrote: which raises the question again: would it be not the better way to build the whole distribution hardened by expierience that nearly anything is exploitable over the long and performance comes after security The logical conclusion from this is to move to a language with automatic memory management. The top vulnerability reports for programs written in C/C++ and most other languages so different that starting a new project that processes untrusted data in C/C++ is becoming indefensible. We seem to be stuck with C as the lowest common denominator that can be used from any runtime; long-term we _need_ to move away from that, or Linux will gain the reputation of least-secure OS around. Now, what to move to? I currently don't have see any language/runtime I could recommend, which is in itself rather frightening. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, 2013-04-15 at 16:55 +0100, Richard W.M. Jones wrote: On Mon, Apr 15, 2013 at 12:08:24PM +0200, Pierre-Yves Chibon wrote: Please tell me, what's wrong with pkgdb and feel free to suggest how it could be fixed. I don't know if pkgdb covers this bit of UI: https://admin.fedoraproject.org/pkgdb but it'd be nice if the Applications button was removed or at least was not the default (the default and possibly the only button should be Packages). This is planned for the next release of pkgdb which is pretty much ready and should happen after the alpha freeze. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Trimming (or obsoleting) %changelog?
Once upon a time, Vít Ondruch vondr...@redhat.com said: Not sure if the age of entry is the only metrics which should be used. What if there was no change in last 3 years? Then we will have just one changelog entry? Just thinking loud ... Especially if there was no upstream release in the last 3 years and there have been security issues (where %changelog entries might be the only documentation that issues have been fixed). Certainly no entries that mention CVEs should be auto-removed if the package version hasn't changed. -- 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: Trimming (or obsoleting) %changelog?
On 04/15/2013 09:05 AM, Pierre-Yves Chibon wrote: On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: Richard Hughes wrote: Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the changelog as long as items that are relevant to the current release are kept intact. Use your best judgement where that position lies. I wonder if there are legal issues involved as the %changelog also list all the person that worked on that spec file. As for all project, in case of licensing changes, you need to know all the authors that ever contributed to the project. But again, IANAL :) I see no legal issues with trimming a %changelog. We don't use that as a commit tracking mechanism in any real way. :) ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On 04/13/2013 07:43 PM, Kevin Kofler wrote: Richard W.M. Jones wrote: This would be excellent, and projects in this area could make a significant contribution. I suspect that any general code-to-policy translator will hit the Halting Problem, since it seems trivial to write a program which would not be possible to translate, but that doesn't mean it can't be solved for many useful real world cases. That's exactly why SELinux policy is the wrong representation. It duplicates information of the code without being automatically transformable either way, requiring every change to be made twice. From the security point of view this is a good thing, because it requires both the programmer's code and the security policy to independently agree to perform every action. Otherwise, the programmer might write 'if (uid=0) then ...' and the automatic policy generator would obediently generate a rule for that. I agree that it's tedious, but practical evidence seems to suggest that it's a converging process and we're almost there---'enforcing' SELinux is a viable setting for a majority of deployments. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
Am 15.04.2013 18:48, schrieb Miloslav Trmač: On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: which raises the question again: would it be not the better way to build the whole distribution hardened by expierience that nearly anything is exploitable over the long and performance comes after security The logical conclusion from this is to move to a language with automatic memory management. The top vulnerability reports for programs written in C/C++ and most other languages so different that starting a new project that processes untrusted data in C/C++ is becoming indefensible. no, that would mean thow away a lot of code and a hurry rewrite of whatelse in whatever language doe snot make things secure We seem to be stuck with C as the lowest common denominator that can be used from any runtime; long-term we _need_ to move away from that, or Linux will gain the reputation of least-secure OS around. not really, proven by securityfocus lists and changelogs of many Fedora apckages which are not in C/C++ a fool will always implement unsecure software and look at java-applets the last year! Now, what to move to? I currently don't have see any language/runtime I could recommend, which is in itself rather frightening and that is why existing technologies to make binaries more secure should be used signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 15.04.2013 18:48, schrieb Miloslav Trmač: On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.netmailto: h.rei...@thelounge.net wrote: which raises the question again: would it be not the better way to build the whole distribution hardened by expierience that nearly anything is exploitable over the long and performance comes after security The logical conclusion from this is to move to a language with automatic memory management. The top vulnerability reports for programs written in C/C++ and most other languages so different that starting a new project that processes untrusted data in C/C++ is becoming indefensible. no, that would mean thow away a lot of code and a hurry rewrite of whatelse in whatever language doe snot make things secure I was not advocating throwing away existing code, merely not continuing to start new projects in C if possible. We seem to be stuck with C as the lowest common denominator that can be used from any runtime; long-term we _need_ to move away from that, or Linux will gain the reputation of least-secure OS around. not really, proven by securityfocus lists and changelogs of many Fedora apckages which are not in C/C++ a fool will always implement unsecure software and look at java-applets the last year! Sure, moving away from C/C++ does not make programs completely secure; however, on average, C/C++ programs are noticeably less secure (because most vulnerabilities that can happen in higher-level languages can also happen in C, but not the other way around). We all wish for programs to be bug-free, but that's just not what happens in the real world. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What to move to? (was: Expanding the list of Hardened Packages)
Miloslav Trmač wrote: The logical conclusion from this is to move to a language with automatic memory management. The top vulnerability reports for programs written in C/C++ and most other languages so different that starting a new project that processes untrusted data in C/C++ is becoming indefensible. If by automatic memory management you mean garbage collection, then that's not really what we need. Garbage collection has advantages, but what is needed to stop the buffer overflows is bounds checking. The compiler needs to keep track of how big each object is and insert code to check that writes to an array stay within the bounds of the array. Now, what to move to? I currently don't have see any language/runtime I could recommend, which is in itself rather frightening. I recommend Ada. Ada does bounds checking, and is compiled to machine code with performance comparable to C. Only compiler bugs can cause buffer overflows in Ada, unless you're so foolhardy that you disable the bounds checking. Coding in Ada reduces not only security holes but also other bugs, because the language is designed to help the programmer avoid mistakes, and to allow the compiler to catch many mistakes as compile-time errors instead of run-time errors. Ada doesn't do garbage collection across the whole program, but features such as controlled types, generic data structures and out parameters greatly reduce the need for garbage collection. The double-free problem is also eliminated. (Garbage collection was made optional in Ada so that the language would be suitable for embedded real-time systems, and in practice most compilers don't provide it.) The disadvantage of Ada is a relative scarcity of libraries. That's not a problem with the language itself but a result of low popularity, and would change with time if more programmers would start using Ada. Help with packaging the libraries that do exist would be welcome. A free compiler? Yes, we have one in Fedora. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Mon, 2013-04-15 at 20:17 +0200, Miloslav Trmač wrote: On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 15.04.2013 18:48, schrieb Miloslav Trmač: On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: which raises the question again: would it be not the better way to build the whole distribution hardened by expierience that nearly anything is exploitable over the long and performance comes after security The logical conclusion from this is to move to a language with automatic memory management. The top vulnerability reports for programs written in C/C++ and most other languages so different that starting a new project that processes untrusted data in C/C++ is becoming indefensible. no, that would mean thow away a lot of code and a hurry rewrite of whatelse in whatever language doe snot make things secure I was not advocating throwing away existing code, merely not continuing to start new projects in C if possible. We seem to be stuck with C as the lowest common denominator that can be used from any runtime; long-term we _need_ to move away from that, or Linux will gain the reputation of least-secure OS around. not really, proven by securityfocus lists and changelogs of many Fedora apckages which are not in C/C++ a fool will always implement unsecure software and look at java-applets the last year! Sure, moving away from C/C++ does not make programs completely secure; however, on average, C/C++ programs are noticeably less secure (because most vulnerabilities that can happen in higher-level languages can also happen in C, but not the other way around). We all wish for programs to be bug-free, but that's just not what happens in the real world. Mirek I believe that you may be right about the vulnerabilities, but the higher level the language, the more hidden vulnerabilities exist, just perhaps not the same ones. I do not believe that C or C++ are inherently less secure than other languages, nor do I believe that there is some statistical way of proving that fact. One can write good or bad code in all languages. It just happens that C is a senior language and due to maturity more of its flaws are known. That doesn't mean newer languages are more secure, only that without sufficient exposure, their flaws have not yet been revealed. Maybe I'm wrong, but given that I won't likely be around by the time these newer languages have become senior, I won't see my statement refuted. Regards, Les H -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
From: les hlhow...@pacbell.net Maybe I'm wrong, but given that I won't likely be around by the time these newer languages have become senior, I won't see my statement refuted. You needn't wait long. Ada has been around for three some decades already. ;-) -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: next pkgdb?
On Mon, 15 Apr 2013 08:41:56 -0500 Bruno Wolff III br...@wolff.to wrote: On Mon, Apr 15, 2013 at 12:55:35 +0200, You might want to have some way to handle getting combinations of access. For example if you request acl access, you really should request all of the rest by default. Commit access should get watchcommits and watchbugs by default. Don't make that unavoidable though; some members of the Perl SIG prefer to see commits and bug reports via the perl-devel list (which is an InitialCC for most perl modules, and all of the ones maintained in this way), and so they have commit access but not the watch accesses. Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote: Now, what to move to? I currently don't have see any language/runtime I could recommend, which is in itself rather frightening. Ada, Eiffel, Go, Coq + OCaml, Erlang, Haskell, CompCert[*], etc. etc. All these languages are viable. I think that programmers falsely think they cannot choose the most suitable language for the task at hand, but my experience is this is more of a mental barrier than a real problem. Rich. [*] Very unfortunately CompCert, a certified correct subset-of-C compiler, is non-free. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
les wrote: I do not believe that C or C++ are inherently less secure than other languages, nor do I believe that there is some statistical way of proving that fact. One can write good or bad code in all languages. I believe you are wrong. Some languages are more secure than other languages. Of course an infallible superhuman could write good code in any language, and a fool can write bad code in any language, but a normal human programmer will write better code in a well-designed language than in an ill-designed language. Björn Persson signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: meswa-libs* breaks X11 fedora 19
On Seg, 2013-04-15 at 07:49 -0500, Brian Millett wrote: I've a dell E6500 running F19. Did a yum upgrade from F18. All has been working great untill I tried to upgrade the following: mesa-libEGL.i686 9.1-6.fc19updates-testing mesa-libEGL.x86_64 9.1-6.fc19updates-testing mesa-libEGL-devel.x86_64 9.1-6.fc19updates-testing mesa-libGL.x86_64 9.1-6.fc19updates-testing mesa-libGL-devel.x86_649.1-6.fc19updates-testing mesa-libGLES.x86_649.1-6.fc19updates-testing mesa-libOSMesa.x86_64 9.1-6.fc19updates-testing mesa-libgbm.i686 9.1-6.fc19updates-testing mesa-libgbm.x86_64 9.1-6.fc19updates-testing mesa-libglapi.i686 9.1-6.fc19updates-testing mesa-libglapi.x86_64 9.1-6.fc19updates-testing Gnome-shell stops, reboot into a blank screen. Had to rollback and it works great. you should open a bug , but since you mention , rollback to what version ? Regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: meswa-libs* breaks X11 fedora 19
On Seg, 2013-04-15 at 23:20 +0100, Sérgio Basto wrote: On Seg, 2013-04-15 at 07:49 -0500, Brian Millett wrote: I've a dell E6500 running F19. Did a yum upgrade from F18. All has been working great untill I tried to upgrade the following: mesa-libEGL.i686 9.1-6.fc19updates-testing mesa-libEGL.x86_64 9.1-6.fc19updates-testing mesa-libEGL-devel.x86_64 9.1-6.fc19updates-testing mesa-libGL.x86_64 9.1-6.fc19updates-testing mesa-libGL-devel.x86_649.1-6.fc19updates-testing mesa-libGLES.x86_649.1-6.fc19updates-testing mesa-libOSMesa.x86_64 9.1-6.fc19updates-testing mesa-libgbm.i686 9.1-6.fc19updates-testing mesa-libgbm.x86_64 9.1-6.fc19updates-testing mesa-libglapi.i686 9.1-6.fc19updates-testing mesa-libglapi.x86_64 9.1-6.fc19updates-testing Gnome-shell stops, reboot into a blank screen. Had to rollback and it works great. you should open a bug , but since you mention , rollback to what version ? Yeah I rollback to 9.1-2.fc19 , and glxinfo begins to work normally , I'm going fill a bug tks -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: meswa-libs* breaks X11 fedora 19
On Ter, 2013-04-16 at 03:05 +0100, Sérgio Basto wrote: On Seg, 2013-04-15 at 23:20 +0100, Sérgio Basto wrote: On Seg, 2013-04-15 at 07:49 -0500, Brian Millett wrote: I've a dell E6500 running F19. Did a yum upgrade from F18. All has been working great untill I tried to upgrade the following: mesa-libEGL.i686 9.1-6.fc19updates-testing mesa-libEGL.x86_64 9.1-6.fc19updates-testing mesa-libEGL-devel.x86_64 9.1-6.fc19updates-testing mesa-libGL.x86_64 9.1-6.fc19updates-testing mesa-libGL-devel.x86_649.1-6.fc19updates-testing mesa-libGLES.x86_649.1-6.fc19updates-testing mesa-libOSMesa.x86_64 9.1-6.fc19updates-testing mesa-libgbm.i686 9.1-6.fc19updates-testing mesa-libgbm.x86_64 9.1-6.fc19updates-testing mesa-libglapi.i686 9.1-6.fc19updates-testing mesa-libglapi.x86_64 9.1-6.fc19updates-testing Gnome-shell stops, reboot into a blank screen. Had to rollback and it works great. you should open a bug , but since you mention , rollback to what version ? Yeah I rollback to 9.1-2.fc19 , and glxinfo begins to work normally , I'm going fill a bug tks https://bugzilla.redhat.com/show_bug.cgi?id=952454 -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Alpha Release Candidate 3 (RC3) Available Now!
NOTE: All DVD and Live images except KDE Live and SoaS Live are still oversize (as they have been since Alpha TC3). As per the Fedora 19 schedule [1], Fedora 19 Alpha Release Candidate 3 (RC3) is now available for testing. Content information, including changes, can be found at https://fedorahosted.org/rel-eng/ticket/5545#comment:23 . Please see the following pages for download links (including delta ISOs) and testing instructions. Normally dl.fedoraproject.org should provide the fastest download, but download-ib01.fedoraproject.org is available as a mirror (with an approximately 1 hour lag) in case of trouble. To use it, just replace dl with download-ib01 in the download URL. Installation: https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Base: https://fedoraproject.org/wiki/Test_Results:Current_Base_Test Desktop: https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test Ideally, all Alpha priority test cases for Installation [2], Base [3], and Desktop [4] should pass in order to meet the Alpha Release Criteria [5]. Help is available on #fedora-qa on irc.freenode.net [6], or on the test list [7]. Create Fedora 19 Alpha test composes (TC) and release candidates (RC) https://fedorahosted.org/rel-eng/ticket/5545 Current Blocker and Freeze Exception bugs: http://qa.fedoraproject.org/blockerbugs/current [1] http://fedorapeople.org/groups/schedule/f-19/f-19-quality-tasks.html [2] https://fedoraproject.org/wiki/QA:Installation_validation_testing [3] https://fedoraproject.org/wiki/QA:Base_validation_testing [4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing [5] https://fedoraproject.org/wiki/Fedora_19_Alpha_Release_Criteria [6] irc://irc.freenode.net/fedora-qa [7] https://admin.fedoraproject.org/mailman/listinfo/test signature.asc Description: OpenPGP digital 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
Another UEFI testing request
Hi folks - thanks for helping out with the last UEFI testing request, it was very helpful. If we could impose again, it would be really helpful if anyone with a UEFI-capable system could try a UEFI native install of Alpha RC3: https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/ and report your results. We are hopeful that the major bugs that affected previous builds are resolved, and many or most UEFI installs should succeed at this point. If you try, please report whether you got a successful installation, and if not, what problem you ran into. Bug reports for problems are of course welcome. Thanks! -- 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
Package review statistics 2013-04-01 - 2013-04-16
Hi, Here are some statistics on package reviews from the first of April. We'll try and get them around more regularly, hopefully on a weekly basis, in the future. Tom, Shawn and Kalev have done more reviews in this period. In total, there were 92 reviews completed: Start Date: 2013-04-01 00:00:00 End Date: 2013-04-16 14:44:01.500771 Tom Hughes : 12 https://bugzilla.redhat.com/show_bug.cgi?id=901452nodejs-dryice https://bugzilla.redhat.com/show_bug.cgi?id=911188nodejs-should https://bugzilla.redhat.com/show_bug.cgi?id=948661nodejs-tunnel-agent https://bugzilla.redhat.com/show_bug.cgi?id=948664nodejs-oauth-sign https://bugzilla.redhat.com/show_bug.cgi?id=948667 nodejs-json-stringify-safe https://bugzilla.redhat.com/show_bug.cgi?id=948669nodejs-hawk https://bugzilla.redhat.com/show_bug.cgi?id=948670nodejs-forever-agent https://bugzilla.redhat.com/show_bug.cgi?id=948671nodejs-aws-sign https://bugzilla.redhat.com/show_bug.cgi?id=949128nodejs-sntp https://bugzilla.redhat.com/show_bug.cgi?id=949457nodejs-hoek https://bugzilla.redhat.com/show_bug.cgi?id=949474nodejs-boom https://bugzilla.redhat.com/show_bug.cgi?id=949485nodejs-cryptiles Shawn Iwinski : 10 https://bugzilla.redhat.com/show_bug.cgi?id=909520 php-horde-Horde-Imap-Client https://bugzilla.redhat.com/show_bug.cgi?id=927894php-horde-Horde-SyncMl https://bugzilla.redhat.com/show_bug.cgi?id=927903 php-horde-Horde-Notification https://bugzilla.redhat.com/show_bug.cgi?id=927920php-pecl-msgpack https://bugzilla.redhat.com/show_bug.cgi?id=928367php-horde-Horde-Feed https://bugzilla.redhat.com/show_bug.cgi?id=928915 php-phpunit-PHPUnit-Story https://bugzilla.redhat.com/show_bug.cgi?id=929038 php-horde-Horde-Kolab-Format https://bugzilla.redhat.com/show_bug.cgi?id=929214php-pear-Net-IMAP https://bugzilla.redhat.com/show_bug.cgi?id=929333php-horde-Horde-Imsp https://bugzilla.redhat.com/show_bug.cgi?id=948275php-phpunit-Version Kalev Lember : 6 https://bugzilla.redhat.com/show_bug.cgi?id=920831lightsoff https://bugzilla.redhat.com/show_bug.cgi?id=920859gnome-klotski https://bugzilla.redhat.com/show_bug.cgi?id=920861gnome-tetravex https://bugzilla.redhat.com/show_bug.cgi?id=947155mingw-gstreamer1 https://bugzilla.redhat.com/show_bug.cgi?id=947587 mingw-gstreamer1-plugins-base https://bugzilla.redhat.com/show_bug.cgi?id=948345mozjs17 Peter Lemenkov : 5 https://bugzilla.redhat.com/show_bug.cgi?id=892625resiprocate https://bugzilla.redhat.com/show_bug.cgi?id=923084python26-psutil https://bugzilla.redhat.com/show_bug.cgi?id=947036wmvolman https://bugzilla.redhat.com/show_bug.cgi?id=947048wmpager https://bugzilla.redhat.com/show_bug.cgi?id=947086wmsystemtray Petr Šabata : 5 https://bugzilla.redhat.com/show_bug.cgi?id=916679perl-ElasticSearch https://bugzilla.redhat.com/show_bug.cgi?id=928418 perl-Devel-GlobalDestruction-XS https://bugzilla.redhat.com/show_bug.cgi?id=947449perl-ExtUtils-Config https://bugzilla.redhat.com/show_bug.cgi?id=947450perl-ExtUtils-Helpers https://bugzilla.redhat.com/show_bug.cgi?id=948974perl-Locale-Maketext Ralph Bean : 4 https://bugzilla.redhat.com/show_bug.cgi?id=948013python-crank https://bugzilla.redhat.com/show_bug.cgi?id=948014python-backlash https://bugzilla.redhat.com/show_bug.cgi?id=948104python-gearbox https://bugzilla.redhat.com/show_bug.cgi?id=950699python-path Michael Scherer : 3 https://bugzilla.redhat.com/show_bug.cgi?id=909471 rubygem-openshift-origin-auth-remote-user https://bugzilla.redhat.com/show_bug.cgi?id=948000gr-osmosdr https://bugzilla.redhat.com/show_bug.cgi?id=949336rtl-sdr Miroslav Suchý : 3 https://bugzilla.redhat.com/show_bug.cgi?id=910146python-SocksipyChain https://bugzilla.redhat.com/show_bug.cgi?id=910699pagekite https://bugzilla.redhat.com/show_bug.cgi?id=951004rubygem-afm T.C. Hollingsworth : 3 https://bugzilla.redhat.com/show_bug.cgi?id=911042nodejs-node-uuid https://bugzilla.redhat.com/show_bug.cgi?id=922481nodejs-JSV https://bugzilla.redhat.com/show_bug.cgi?id=922488nodejs-node-markdown Ankur Sinha (FranciscoD) : 2 https://bugzilla.redhat.com/show_bug.cgi?id=871197catkin https://bugzilla.redhat.com/show_bug.cgi?id=871204urdfdom-headers Bohuslav Slavek Kabrda : 2 https://bugzilla.redhat.com/show_bug.cgi?id=929083python-peewee https://bugzilla.redhat.com/show_bug.cgi?id=929189python-flask-script Eduardo Echeverria : 2 https://bugzilla.redhat.com/show_bug.cgi?id=923564NetworkManager-ssh https://bugzilla.redhat.com/show_bug.cgi?id=928061nagstamon Erik van Pienbroek : 2 https://bugzilla.redhat.com/show_bug.cgi?id=858064
File ExtUtils-Helpers-0.016.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-ExtUtils-Helpers: dac17d14ef75b11246551bbac73694ad ExtUtils-Helpers-0.016.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-ExtUtils-Helpers] Update to 0.016
commit ea02e0aecf465e6e4854fc93101a118316b7297f
Author: Paul Howarth p...@city-fan.org
Date: Mon Apr 15 09:46:25 2013 +0100
Update to 0.016
- New upstream release 0.016
- Made man3_pagename more flexible with paths
- Reverted pl2bat to a more original state
- Rewrote fixin code
- Re-added detildefy
- Add some fixes to batch file generation
- BR: perl(Carp) and perl(Module::Load), now required by the module
- Drop BR: perl(Test::Kwalitee), no longer used
- Update patch for using Test::ParseWords 3.22
- Drop now-redundant POD encoding patch
ExtUtils-Helpers-0.014-pod.patch | 11
...tUtils-Helpers-0.016-old-Text::ParseWords.patch |8 +++---
perl-ExtUtils-Helpers.spec | 25 +--
sources|2 +-
4 files changed, 22 insertions(+), 24 deletions(-)
---
diff --git a/ExtUtils-Helpers-0.014-old-Text::ParseWords.patch
b/ExtUtils-Helpers-0.016-old-Text::ParseWords.patch
similarity index 59%
rename from ExtUtils-Helpers-0.014-old-Text::ParseWords.patch
rename to ExtUtils-Helpers-0.016-old-Text::ParseWords.patch
index eb021a0..f6edaff 100644
--- a/ExtUtils-Helpers-0.014-old-Text::ParseWords.patch
+++ b/ExtUtils-Helpers-0.016-old-Text::ParseWords.patch
@@ -1,11 +1,11 @@
--- lib/ExtUtils/Helpers/Unix.pm
+++ lib/ExtUtils/Helpers/Unix.pm
-@@ -8,7 +8,7 @@
- use Exporter 5.57 'import';
- our @EXPORT = qw/make_executable split_like_shell/;
+@@ -10,7 +10,7 @@
+ use Carp qw/croak/;
+ use Config;
-use Text::ParseWords 3.24 qw/shellwords/;
+use Text::ParseWords 3.22 qw/shellwords/;
- use ExtUtils::MakeMaker;
sub make_executable {
+ my $filename = shift;
diff --git a/perl-ExtUtils-Helpers.spec b/perl-ExtUtils-Helpers.spec
index 1c601e8..c32415b 100644
--- a/perl-ExtUtils-Helpers.spec
+++ b/perl-ExtUtils-Helpers.spec
@@ -5,26 +5,27 @@
%global old_test_more %(perl -MTest::More -e 'print (($Test::More::VERSION)
0.88 ? 1 : 0);' 2/dev/null || echo 0)
Name: perl-ExtUtils-Helpers
-Version: 0.014
-Release: 2%{?dist}
+Version: 0.016
+Release: 1%{?dist}
Summary: Various portability utilities for module builders
Group: Development/Libraries
License: GPL+ or Artistic
URL: https://metacpan.org/release/ExtUtils-Helpers
Source0:
http://cpan.metacpan.org/authors/id/L/LE/LEONT/ExtUtils-Helpers-%{version}.tar.gz
-Patch1:ExtUtils-Helpers-0.014-pod.patch
-Patch2:ExtUtils-Helpers-0.014-old-Text::ParseWords.patch
+Patch2:ExtUtils-Helpers-0.016-old-Text::ParseWords.patch
Patch3:ExtUtils-Helpers-0.014-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
# Build
BuildRequires: perl(ExtUtils::MakeMaker)
# Module
+BuildRequires: perl(Carp)
BuildRequires: perl(Config)
BuildRequires: perl(Exporter) = 5.57
BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Spec::Functions)
+BuildRequires: perl(Module::Load)
BuildRequires: perl(Pod::Man)
BuildRequires: perl(Text::ParseWords) = 3.22
# Test Suite
@@ -34,7 +35,6 @@ BuildRequires:perl(File::Temp)
BuildRequires: perl(Test::More)
# Release Tests
BuildRequires: perl(Pod::Coverage::TrustPod)
-BuildRequires: perl(Test::Kwalitee)
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
# Runtime
@@ -47,9 +47,6 @@ modules.
%prep
%setup -q -n ExtUtils-Helpers-%{version}
-# Specify POD encoding
-%patch1
-
# We don't really need Text::ParseWords ≥ 3.24
%if %{old_tpw}
%patch2
@@ -85,6 +82,18 @@ rm -rf %{buildroot}
%{_mandir}/man3/ExtUtils::Helpers::Windows.3pm*
%changelog
+* Sat Apr 13 2013 Paul Howarth p...@city-fan.org - 0.016-1
+- Update to 0.016
+ - Made man3_pagename more flexible with paths
+ - Reverted pl2bat to a more original state
+ - Rewrote fixin code
+ - Re-added detildefy
+ - Add some fixes to batch file generation
+- BR: perl(Carp) and perl(Module::Load), now required by the module
+- Drop BR: perl(Test::Kwalitee), no longer used
+- Update patch for using Test::ParseWords 3.22
+- Drop now-redundant POD encoding patch
+
* Mon Apr 1 2013 Paul Howarth p...@city-fan.org - 0.014-2
- Sanitize for Fedora submission
diff --git a/sources b/sources
index 868ed08..b7f21a3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fb98fda3d6e1a3a98758e944495157ec ExtUtils-Helpers-0.014.tar.gz
+dac17d14ef75b11246551bbac73694ad ExtUtils-Helpers-0.016.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-ExtUtils-Helpers/f19] Update to 0.016
Summary of changes: ea02e0a... Update to 0.016 (*) (*) 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-ExtUtils-Helpers/f18] Update to 0.016
Summary of changes: ea02e0a... Update to 0.016 (*) (*) 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-ExtUtils-Helpers/f17] Update to 0.016
Summary of changes: ea02e0a... Update to 0.016 (*) (*) 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-ExtUtils-Helpers/el6] Update to 0.016
Summary of changes: ea02e0a... Update to 0.016 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 952130] New: Provide perl-podlators
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 Bug ID: 952130 Summary: Provide perl-podlators Product: Fedora Version: 18 Component: perl Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: gia...@gmail.com QA Contact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, iarn...@gmail.com, jples...@redhat.com, ka...@ucw.cz, lkund...@v3.sk, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com, rc040...@freenet.de, tcall...@redhat.com Category: --- perl-podlators is a new subpackage in the F19 branch which is then buildrequired by some packages. I am getting an error in rebuilding one of these in F18 because of this. Can you please add a Provides: perl-podlators given the equivalent functions are in the main package in F18 ? That would save me a lot of trouble in this rebuild effort. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=0bIL8kfizca=cc_unsubscribe -- 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-ExtUtils-Helpers/el5] Update to 0.016
Summary of changes: ea02e0a... Update to 0.016 (*) (*) 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-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.016-1.el5
The lightweight tag 'perl-ExtUtils-Helpers-0.016-1.el5' was created pointing to: ea02e0a... Update to 0.016 -- 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-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.016-1.el6
The lightweight tag 'perl-ExtUtils-Helpers-0.016-1.el6' was created pointing to: ea02e0a... Update to 0.016 -- 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-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.016-1.fc17
The lightweight tag 'perl-ExtUtils-Helpers-0.016-1.fc17' was created pointing to: ea02e0a... Update to 0.016 -- 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-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.016-1.fc18
The lightweight tag 'perl-ExtUtils-Helpers-0.016-1.fc18' was created pointing to: ea02e0a... Update to 0.016 -- 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-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.016-1.fc19
The lightweight tag 'perl-ExtUtils-Helpers-0.016-1.fc19' was created pointing to: ea02e0a... Update to 0.016 -- 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-ExtUtils-Helpers] Created tag perl-ExtUtils-Helpers-0.016-1.fc20
The lightweight tag 'perl-ExtUtils-Helpers-0.016-1.fc20' was created pointing to: ea02e0a... Update to 0.016 -- 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 952130] Provide perl-podlators
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2013-04-15 05:51:10 --- Comment #1 from Petr Pisar ppi...@redhat.com --- No, we cannot. We do not back-port feature changes into old stable Fedoras. Please modify you spec file. Each Fedora release is unique. That's the reason why we have git branches. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=lpEUE2mBv8a=cc_unsubscribe -- 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 IO-Socket-SSL-1.85.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 53513ee1d14d36af99c4f3eb895d6dbf IO-Socket-SSL-1.85.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 952130] Provide perl-podlators
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 Paul Howarth p...@city-fan.org changed: What|Removed |Added CC||p...@city-fan.org --- Comment #2 from Paul Howarth p...@city-fan.org --- Instead of having perl-podlators as a build requirement, a better option that would work on both old and new versions of Fedora would be to add a build requirement that specifies what's actually needed, which would typically be /usr/bin/pod2man or a module name such as perl(Pod::Man). -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k1lGo9FUfAa=cc_unsubscribe -- 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-IO-Socket-SSL] Update to 1.85
commit ff458068d89e39e5e278a487764c03348c81f1c5
Author: Paul Howarth p...@city-fan.org
Date: Mon Apr 15 11:12:28 2013 +0100
Update to 1.85
- New upstream release 1.85
- Probe for available modules with local __DIE__ and __WARN__handlers
(CPAN RT#84574)
- Fix warning, when IO::Socket::IP is installed and inet6 support gets
explictly
requested (CPAN RT#84619)
perl-IO-Socket-SSL.spec |9 -
sources |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index 1e9731a..73e49dc 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.84
+Version: 1.85
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -66,6 +66,13 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL.3pm*
%changelog
+* Mon Apr 15 2013 Paul Howarth p...@city-fan.org - 1.85-1
+- Update to 1.85
+ - Probe for available modules with local __DIE__ and __WARN__handlers
+(CPAN RT#84574)
+ - Fix warning, when IO::Socket::IP is installed and inet6 support gets
explictly
+requested (CPAN RT#84619)
+
* Sat Feb 16 2013 Paul Howarth p...@city-fan.org - 1.84-1
- Update to 1.84
- Disabled client side SNI for openssl version 1.0.0 because of
diff --git a/sources b/sources
index caae868..ab7e97c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3878d8c84c1e8a611f4d0d9b3574ce35 IO-Socket-SSL-1.84.tar.gz
+53513ee1d14d36af99c4f3eb895d6dbf IO-Socket-SSL-1.85.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-IO-Socket-SSL/f19] Update to 1.85
Summary of changes: ff45806... Update to 1.85 (*) (*) 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-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.85-1.fc19
The lightweight tag 'perl-IO-Socket-SSL-1.85-1.fc19' was created pointing to: ff45806... Update to 1.85 -- 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-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.85-1.fc20
The lightweight tag 'perl-IO-Socket-SSL-1.85-1.fc20' was created pointing to: ff45806... Update to 1.85 -- 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 952175] New: perl-App-cpanminus-1.6108 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952175 Bug ID: 952175 Summary: perl-App-cpanminus-1.6108 is available Product: Fedora Version: rawhide Component: perl-App-cpanminus Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org Category: --- Latest upstream release: 1.6108 Current version in Fedora Rawhide: 1.6107 URL: http://search.cpan.org/dist/App-cpanminus/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=3UNcy3BdUga=cc_unsubscribe -- 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 952177] New: perl-CPAN-Mini-1.111013 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952177 Bug ID: 952177 Summary: perl-CPAN-Mini-1.111013 is available Product: Fedora Version: rawhide Component: perl-CPAN-Mini Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com Category: --- Latest upstream release: 1.111013 Current version in Fedora Rawhide: 1.111012 URL: http://search.cpan.org/dist/CPAN-Mini/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=jGb3ke3HZla=cc_unsubscribe -- 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 952179] New: perl-File-Fetch-0.42 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952179 Bug ID: 952179 Summary: perl-File-Fetch-0.42 is available Product: Fedora Version: rawhide Component: perl-File-Fetch Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Category: --- Latest upstream release: 0.42 Current version in Fedora Rawhide: 0.38 URL: http://search.cpan.org/dist/File-Fetch/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fLnlYRriYQa=cc_unsubscribe -- 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 952180] New: perl-File-Temp-0.2301 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952180 Bug ID: 952180 Summary: perl-File-Temp-0.2301 is available Product: Fedora Version: rawhide Component: perl-File-Temp Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Category: --- Latest upstream release: 0.2301 Current version in Fedora Rawhide: 0.23 URL: http://search.cpan.org/dist/File-Temp/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=4f9gPV6Cj8a=cc_unsubscribe -- 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 952184] New: perl-Test-Class-0.39 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952184 Bug ID: 952184 Summary: perl-Test-Class-0.39 is available Product: Fedora Version: rawhide Component: perl-Test-Class Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: st...@silug.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, st...@silug.org Category: --- Latest upstream release: 0.39 Current version in Fedora Rawhide: 0.38 URL: http://search.cpan.org/dist/Test-Class/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=DmKNEBvM9Ra=cc_unsubscribe -- 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 952185] New: perl-Wx-0.9921 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952185 Bug ID: 952185 Summary: perl-Wx-0.9921 is available Product: Fedora Version: rawhide Component: perl-Wx Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: tcall...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, tcall...@redhat.com Category: --- Latest upstream release: 0.9921 Current version in Fedora Rawhide: 0.9918 URL: http://search.cpan.org/dist/Wx/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XQoDlzOFEGa=cc_unsubscribe -- 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 952186] New: perl-XML-LibXML-2.0016 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952186 Bug ID: 952186 Summary: perl-XML-LibXML-2.0016 is available Product: Fedora Version: rawhide Component: perl-XML-LibXML Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Category: --- Latest upstream release: 2.0016 Current version in Fedora Rawhide: 2.0014 URL: http://search.cpan.org/dist/XML-LibXML/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=OQ6RofBikPa=cc_unsubscribe -- 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 781417] perl-XML-Writer-0.621 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=781417 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-XML-Writer-0.615 is|perl-XML-Writer-0.621 is |available |available --- Comment #2 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.621 Current version in Fedora Rawhide: 0.612 URL: http://search.cpan.org/dist/XML-Writer/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=SQw8bt0SFQa=cc_unsubscribe -- 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 952175] perl-App-cpanminus-1.6108 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952175 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com |ppi...@redhat.com Assignee|mmasl...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=fJI0L6MR5Ma=cc_unsubscribe -- 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 App-cpanminus-1.6108.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-App-cpanminus: 59bbb83869f34feaa592cb76e5103746 App-cpanminus-1.6108.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
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the rawhide tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-App-cpanminus] 1.6108 bump
commit 78f490247eeb7bfed8f4a27a5aa779460efd964c
Author: Petr Písař ppi...@redhat.com
Date: Mon Apr 15 13:08:45 2013 +0200
1.6108 bump
.gitignore |1 +
perl-App-cpanminus.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c872e34..d039e39 100644
--- a/.gitignore
+++ b/.gitignore
@@ -44,3 +44,4 @@ App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.6104.tar.gz
/App-cpanminus-1.6105.tar.gz
/App-cpanminus-1.6107.tar.gz
+/App-cpanminus-1.6108.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index 6791039..48bc991 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpanminus
-Version:1.6107
+Version:1.6108
Release:1%{?dist}
Summary:Get, unpack, build and install CPAN modules
License:GPL+ or Artistic
@@ -93,6 +93,9 @@ make test
%{_bindir}/cpanm
%changelog
+* Mon Apr 15 2013 Petr Pisar ppi...@redhat.com - 1.6108-1
+- 1.6108 bump
+
* Mon Apr 08 2013 Petr Pisar ppi...@redhat.com - 1.6107-1
- 1.6107 bump
diff --git a/sources b/sources
index 104c38a..4054e0c 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-be611dce0f19a38b522660370eb763f9 App-cpanminus-1.6107.tar.gz
+59bbb83869f34feaa592cb76e5103746 App-cpanminus-1.6108.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 952177] perl-CPAN-Mini-1.111013 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952177 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC|mmasl...@redhat.com,|ppi...@redhat.com |psab...@redhat.com | Assignee|mmasl...@redhat.com |ppi...@redhat.com -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=aBaL4FFoMZa=cc_unsubscribe -- 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 952175] perl-App-cpanminus-1.6108 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952175 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpanminus-1.6108-1 ||.fc20 Resolution|--- |RAWHIDE Last Closed||2013-04-15 07:16:53 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cIKBFCC8ssa=cc_unsubscribe -- 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 CPAN-Mini-1.111013.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-CPAN-Mini: 7c2cdf9defca583af99e4ae76c1eb18f CPAN-Mini-1.111013.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-CPAN-Mini] 1.111013 bump
commit b338a77c476635edeaa0c23e9bc5edb54dca2877
Author: Petr Písař ppi...@redhat.com
Date: Mon Apr 15 13:46:39 2013 +0200
1.111013 bump
.gitignore |1 +
perl-CPAN-Mini.spec | 30 +++---
sources |2 +-
3 files changed, 25 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 88023a6..7ba6c59 100644
--- a/.gitignore
+++ b/.gitignore
@@ -5,3 +5,4 @@ CPAN-Mini-1.100630.tar.gz
/CPAN-Mini-1.111010.tar.gz
/CPAN-Mini-1.111011.tar.gz
/CPAN-Mini-1.111012.tar.gz
+/CPAN-Mini-1.111013.tar.gz
diff --git a/perl-CPAN-Mini.spec b/perl-CPAN-Mini.spec
index 492d0e0..8723701 100644
--- a/perl-CPAN-Mini.spec
+++ b/perl-CPAN-Mini.spec
@@ -1,17 +1,24 @@
Name: perl-CPAN-Mini
Summary:Create a minimal mirror of CPAN
-Version:1.111012
+Version:1.111013
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/CPAN-Mini-%{version}.tar.gz
URL:http://search.cpan.org/dist/CPAN-Mini/
-Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
BuildArch: noarch
BuildRequires: perl
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time:
BuildRequires: perl(Carp)
BuildRequires: perl(Compress::Zlib) = 1.20
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
+BuildRequires: perl(CPAN)
+BuildRequires: perl(CPANPLUS::Backend)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Find)
BuildRequires: perl(File::HomeDir) = 0.57
BuildRequires: perl(File::Path) = 2.04
BuildRequires: perl(File::Spec)
@@ -19,11 +26,17 @@ BuildRequires: perl(File::Temp)
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(LWP::UserAgent) = 5
BuildRequires: perl(Pod::Usage) = 1.00
-BuildRequires: perl(Test::More) = 0.96
BuildRequires: perl(URI) = 1
+# Tests:
+BuildRequires: perl(Test::More) = 0.96
+# Optional tests:
+BuildRequires: perl(Test::Script) = 1.05
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(CPAN)
+Requires: perl(CPANPLUS::Backend)
%{?perl_default_filter}
-%global __requires_exclude %__requires_exclude|perl\\(File::HomeDir\\)$
+%global __requires_exclude %__requires_exclude|^perl\\(File::HomeDir\\)$
%description
CPAN::Mini provides a simple mechanism to build and update a minimal
@@ -32,7 +45,6 @@ needed to install the newest version of every distribution.
%prep
%setup -q -n CPAN-Mini-%{version}
-perl -pi -e 's|^#!perl|#!/usr/bin/perl|' t/*
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -47,12 +59,16 @@ find %{buildroot} -type f -name .packlist -exec rm -f {} +
make test
%files
-%doc Changes LICENSE README t/
+%doc Changes LICENSE README
%{_bindir}/*
%{perl_vendorlib}/*
%{_mandir}/man[13]/*
%changelog
+* Mon Apr 15 2013 Petr Pisar ppi...@redhat.com - 1.111013-1
+- 1.111013 bump
+- Stop packaging internal tests
+
* Tue Apr 02 2013 Petr Pisar ppi...@redhat.com - 1.111012-1
- 1.111012 bump
diff --git a/sources b/sources
index a21afa2..8fbd7b4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2a1085a15e09d77e885db750472793e3 CPAN-Mini-1.111012.tar.gz
+7c2cdf9defca583af99e4ae76c1eb18f CPAN-Mini-1.111013.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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the F-19 tree: On x86_64: perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.x86_64 requires perl(Bio::PrimarySeq) On i386: perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::SeqFeature::Lite) perl-Bio-SamTools-1.35-2.fc19.i686 requires perl(Bio::PrimarySeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-ASN1-EntrezGene
perl-Bio-ASN1-EntrezGene has broken dependencies in the F-19 tree: On x86_64: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) On i386: perl-Bio-ASN1-EntrezGene-1.091-17.fc19.noarch requires perl(Bio::Index::AbstractSeq) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the F-19 tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
