Koji failure in f19: class 'koji.ActionNotAllowed': tag requires admin permission
Subject: libguestfs-1.21.25-1.fc19 unsuccessfully tagged into f19 by rjones Package: libguestfs NVR: libguestfs-1.21.25-1.fc19 User: rjones Status: failed Tag Operation: tagged Into Tag: f19 libguestfs-1.21.25-1.fc19 unsuccessfully tagged into f19 by rjones Operation failed with the error: class 'koji.ActionNotAllowed': tag requires admin permission ... During the build the error was: 5195632 build (f19-candidate, /libguestfs:ae9c6c49db350b2a60503b7aac4138eda0cca421): FAILED: ActionNotAllowed: tag requires admin permission 5195651 buildArch (libguestfs-1.21.25-1.fc19.src.rpm, i686): closed 5195633 buildSRPMFromSCM (/libguestfs:ae9c6c49db350b2a60503b7aac4138eda0cca421): closed 5196802 tagBuild (noarch): FAILED: ActionNotAllowed: tag requires admin permission 5195650 buildArch (libguestfs-1.21.25-1.fc19.src.rpm, x86_64): closed 5195632 build (f19-candidate, /libguestfs:ae9c6c49db350b2a60503b7aac4138eda0cca421) failed What does this mean and how to fix it? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
RE: Koji failure in f19: : tag requiresadmin permission
Hello: Subject: libguestfs-1.21.25-1.fc19 unsuccessfully tagged into f19 by rjones Package: libguestfs NVR: libguestfs-1.21.25-1.fc19 User: rjones Status: failed Tag Operation: tagged Into Tag: f19 libguestfs-1.21.25-1.fc19 unsuccessfully tagged into f19 by rjones Operation failed with the error: : tag requires admin permission What does this mean and how to fix it? Rich. I guess your build was hit by F-19 alpha change freeze: http://lists.fedoraproject.org/pipermail/devel/2013-April/180922.html You may try tagging your build as f19-candidate. If it doesn't succeed, just bumping release and rebuilding is simple way. Anyway you have to submit your build on bodhi. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] OpenStack Test Day today (Tuesday)
It's Test Day time again today, folks. Sorry for the short notice - looks like everyone was expecting someone else to send the announcement mail... Today - 2013-04-02 - is OpenStack Test Day: https://fedoraproject.org/wiki/Test_Day:2013-04-02_OpenStack Please do come out and help us test the integration of OpenStack into Fedora 19! All the testing instructions are on the wiki, and there are people standing by in #fedora-test-day to help with testing and discuss results. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: any hope for logstash?
Dne 30.3.2013 03:31, gil napsal(a): Il 30/03/2013 01:16, Carl Byington ha scritto: I am working on packaging logstash http://www.logstash.net/ but the build procedure described here https://github.com/logstash/logstash/wiki/ Building-and-running-logstash-from-source seems to be incompatible with Fedora packaging. How do other jruby packages (are there any?) deal with this? hi, take a look here https://bugzilla.redhat.com/show_bug.cgi?id=821146 regards http://www.five-ten-sg.com/mapper/logstash/ points to a method to build a source rpm, but it is source only if you consider a java .jar file to be source code. At least that lets me install this on multiple machines easily. Hi guys, We should reiterate this. There was significant changes in JRuby packaging for F19/Rawhide. We should be able to package it as a gem for JRuby. However, this was never done before, so it will be more or less proof of concept. We should also clarify naming conventions, macros, etc. Would you mind to join Ruby-SIG ML to discuss this topic there? Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[heads-up] st license change
Please note that with the 0.4 update (landing in rawhide and f19 now), st has switched from BSD to MIT license. [1] Petr [1] http://lists.suckless.org/dev/1303/15030.html pgpn_yaryx9lo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
John Reiser jrei...@bitwagon.com wrote:
It's also easy to see the mechanism:
$ cat foo.c
extern int a[];
void foo(int j) { a[j]=j; }
$ gcc -m32 -fPIE -O -S foo.c
$ cat foo.s # edited for brevity
foo: # 25 bytes; about 15 cycles (incl. 3*3 cycles data cache fetch latency)
call__x86.get_pc_thunk.cx
addl$_GLOBAL_OFFSET_TABLE_, %ecx
movl4(%esp), %eax
movla@GOT(%ecx), %edx
movl%eax, (%edx,%eax,4)
ret
Yes, but... Am I right in thinking that a page containing the above can be
shared, but...
$ gcc -m32 -O -S foo.c
$ cat foo.s # edited for brevity
foo: # 12 bytes; about 6 cycles (incl. 1*3 cycles data cache fetch latency)
movl4(%esp), %eax
movl%eax, a(,%eax,4)
ret
$
... a page containing this cannot because it must be relocated prior to
execution?
Admittedly, it is possible that if the address stored by the linker for 'a' is
the same as 'a' is loaded at, then the loader might not need to adjust the
instruction - but if we randomise the load addresses of various binaries, then
that is unlikely to be true.
David
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
Dne 29.3.2013 22:49, Nicolas Mailhot napsal(a): This is what I am taking about: http://www.devconf.cz/slides/mls-pkgmgmt2.pdf http://www.youtube.com/watch?v=FNwNF19oFqM The most interesting parts of the presentation IMHO are : 1. the acknowledgement that sometimes, you really need operators such as AND and OR to express some constrains cleanly 2. the acknowledgement some provides want to be in list/tuple form (and the package management should be able to identify the correct package when the user requests an element in this list) But the solutions presented for those needs are more hacks and prototypes than definitive answers. I think they solved the dependency solving, which is IMO the hardest part, in libsolv and they are missing support for appropriate metadata in RPM. That is why it looks so hacky. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 946889] perl-Text-CSV_XS-0.97 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=946889 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Text-CSV_XS-0.97-1.fc1 ||9 Resolution|--- |RAWHIDE Last Closed||2013-04-02 04:16:54 -- 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=wGwVXqJ5WLa=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: dependency problem with my (first) RPM
On mar, 2013-04-02 at 08:32 +0800, Christopher Meng wrote: %define _binaries_in_noarch_packages_terminate_build 0 ? That didn't do anything... Perhaps because what I'm seeing is a `yum install' issue, rather than a `rpmbuild -ba' issue? Thanks anyway, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependency problem with my (first) RPM
On lun, 2013-04-01 at 12:14 +0200, Reindl Harald wrote: Am 01.04.2013 12:02, schrieb Miro Hrončok: Dne 1.4.2013 10:17, Dario Faggioli napsal(a): I googled for this quite a bit, but I don't seem to be able to find anything explaining how to make that Requires: perl(any) go away... :-( If you just want it to go away, try this: http://fedoraproject.org/wiki/Packaging:AutoProvidesAndRequiresFiltering But I would focus on why it happened. (No, I don't know that.) BuildArch: noarch Requires: perl (which is not noarch) Oh... I see. Sorry, didn't think about that! :-P Actually, I gave it a try to a version of the spec file without the noarch, which produced an fc18.x86_64 package, but got the same result when trying to install it... Requires: /usr/bin/perl That does not seem to change much, at the end o the output of `rpmbuild -ba' I'm still seeing this: Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(FileDigests) = 4.6.0-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Requires: /bin/sh /usr/bin/perl perl(Carp) perl(Digest::MD5) perl(English) perl(Env) perl(File::Copy) perl(File::Path) perl(File::Slurp) perl(File::Spec) perl(File::Temp) perl(Getopt::Long) perl(Moose) perl(POSIX) perl(Pod::Usage) perl(Text::Template) perl(Xen::Tools::Log) perl(any) perl(strict) perl(warnings) i.e., perl(any) is still there, and that is still where trying to install the package dies. :-( r try to remove it completly i would wonder if the perl base pakcage can be uninstalled Sorry, what do you mean by try to remove it completely ? Thanks a lot for replying, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dependency problem with my (first) RPM
On lun, 2013-04-01 at 13:19 +0200, Miro Hrončok wrote: Dne 1.4.2013 12:42, Michael Schwendt napsal(a): RPM's automatic Perl dependency generator isn't 100% and has found something like use any in a Perl module or source file. You either need to work around that by changing that text or filter it out with the help of Requires filtering. Seems like this: WARNING --- You appear to have a missing vif-script, or network-script, in the Xen configuration file /etc/xen/xend-config.sxp. Please fix this and restart Xend, or your guests will not be able to use any networking! HERE !!! OMG! Thanks a lot (to both, Michael and Miro!)... Neither my perl nor my knowledge of RPM would have allowed me to spot this, at least for the next geologic era I guess!! :-P I'll discuss about that with upstream and look into Requires filtering. Thanks a ton again, Dario -- This happens because I choose it to happen! (Raistlin Majere) - Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems RD Ltd., Cambridge (UK) signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On 04/01/13 at 03:05pm, Dhiru Kholia wrote: On 04/01/13 at 10:23am, Michael Scherer wrote: Le lundi 01 avril 2013 à 12:29 +0530, Dhiru Kholia a écrit : It would be great to have some sort of automated method to find if hardening criteria applies to a particular package. Ideas are welcome! You can take a look on http://people.redhat.com/sgrubb/security/ , there is a script rpm-chksec to verify that. Thanks! I found some neat ideas in rpm-chksec script. I will incorporate them into https://github.com/kholia/checksec Here is a list of packages (daemons only) which are (possibly) violating packaging guidelines with respect to hardening. http://dl.dropbox.com/u/1522424/probable-violations-F19.xls (Please note that this list was generated by a program and might be buggy!) -- Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 926018] perl-DBI-1.625 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=926018 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-DBI-1.625-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-04-02 08:22:35 -- 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=5WYhcy6BQ3a=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: Using Fedora for Gnome development...
On Mon, Apr 01, 2013 at 04:56:34PM -0400, Colin Walters wrote: On Mon, 2013-04-01 at 16:26 -0400, Darryl L. Pierce wrote: When I ran this (which is where I ran into problems) jhbuild installs python3 and its dependencies, which is what's borking my day job development. That's odd. How did you install jhbuild? Oh...did you run jhbuild bootstrap? Don't do that. If you did, delete your build directory and start over. The steps I followed were: 1. clone the jhbuild repo 2. ./autogen.sh 3. make 4. make install 5. cd into the gnome-music repo and 6. jhbuild sysdeps --install This pulls in python3 from the Fedora repos. -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.multiply.com/ What do you care what people think, Mr. Feynman? pgpTuFLmitIWb.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-19 Branched report: 20130402 changes
Compose started at Tue Apr 2 09:15:19 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: Expanding the list of Hardened Packages
On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote: http://dl.dropbox.com/u/1522424/probable-violations-F19.xls That shows: D0CF^QU+0871^ZE1^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@FEFF ^@^F^@^@^@^@^@^@^@^@^@^@^@^F^@^@^@E6^B^@^@^@^@^@^@^@^P^@^@FEFF^@^@^@^@FEFF^@^@^@^@E0^B^@^@E1^B^@^@E2^B^@^@E3^B^@^@E4^B^@^@E5^B^@^@ Can you use a non-proprietary format please. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Tue, Apr 2, 2013 at 6:36 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote: http://dl.dropbox.com/u/1522424/probable-violations-F19.xls That shows: garbage Can you use a non-proprietary format please. Can you try wget http://dl.dropbox.com/u/1522424/probable-violations-F19.xls; ? This file was generated using open-source tools and it works great on LibreOffice. I can generate a CSV file if you really want it. -- Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On 2013-03-29, seth vidal skvi...@fedoraproject.org wrote: On Fri, 29 Mar 2013 14:01:29 + (UTC) Petr Pisar ppi...@redhat.com wrote: What's Architecture good for? To allow multilib. To install more instances of the same version. And yum ignores Architecture on purpose. But don't tell anybody that. Otherwise he could not claim we do not implement parallel installation. Yum ignores arch? Since when? Maybe you're using the word 'ignores' in a way I'm not familiar with. Yes, I used it a little metaphorically. yum install foo.i386 does exactly what you think it does. yum install foo installs the bestarch is can find for that pkgname. That's exactly the goal. Yum _understands_ architecture. It allows you to install, upgrade, remove architecteruces independetly, yet it allow to substistute one with another one to meet dependencies. Misusing names does not allow all of that. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using Fedora for Gnome development...
On Tuesday, April 02, 2013 08:25 PM, Darryl L. Pierce wrote: On Mon, Apr 01, 2013 at 04:56:34PM -0400, Colin Walters wrote: On Mon, 2013-04-01 at 16:26 -0400, Darryl L. Pierce wrote: When I ran this (which is where I ran into problems) jhbuild installs python3 and its dependencies, which is what's borking my day job development. That's odd. How did you install jhbuild? Oh...did you run jhbuild bootstrap? Don't do that. If you did, delete your build directory and start over. The steps I followed were: 1. clone the jhbuild repo 2. ./autogen.sh 3. make 4. make install 5. cd into the gnome-music repo and 6. jhbuild sysdeps --install This pulls in python3 from the Fedora repos. You can perfectly well have Python 2 and 3 coexisting on the same Fedora, and use either in your projects. The packages are made to be installed in parallel, and there shouldn't be any conflicts. Many people are developing applications in Python 2 or Python 3 on the same Fedora machine (myself included). Unless you're hitting a bug, of course. Could you give more details on what the problem actually is? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130330 changes
Dne 30.3.2013 20:02, Kevin Fenzi napsal(a): There's a number of ruby ones. I'm not sure what to do with these. The abi is hard coded, so it would be easy to change and rebuild, but I have no idea if the packages work correctly with the new ruby. Ruby sig folks: Anyone working on these? [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [rubygem-aeolus-cli] [rubygem-aeolus-image] Aeolus guys are hopefully aware of this (adding mmorsi into CC). [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) = 0:1.9.1 This is blocked by rubygem-syck, which was removed from Ruby. There is ongoing review of rubygem-syck, but I believe that the application should be ported to rubygem-psych. [deltacloud-core] deltacloud-core-1.0.5-2.fc19.noarch requires ruby(abi) = 0:1.9.1 Deltacloud guys are aware of this (adding mfojtik on CC). [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) (the eruby home page is now a parking site. Perhaps this package should be retired now?) Well, it is one possibility. I already looked into the issue, but did not find solution in reasonable time. rubygem-apipie-rails Updated to the latest upstream version. rubygem-boxgrinder-build rubygem-boxgrinder-core Hopefully upstream is aware (adding mgoldman on CC), however there is certainly incompatibility due to missing sych in recetn Ruby. rubygem-dynamic_form Is in semiretired state [2] :/ rubygem-gem2rpm Incompatible with RubyGems 2.0. Patch proposed to upstream, but it needs more love. rubygem-gettext_i18n_rails Blocked by rubygem-slim rubygem-pam This would need some .spec file cleanup. I gave up for the moment. rubygem-qpid_proton It was already rebuilt I believe. rubygem-rack-mount Not maintained upstream, there were some issues if I remember correctly. May be should be retired, as it was part of Ruby on Rails 3.0.x but it is not anymore. rubygem-slim Blocked by upstream as far as I know. [tpp] tpp-1.3.1-11.fc19.noarch requires ruby(abi) = 0:1.8 [xmms2] xmms2-ruby-0.8-8.fc19.x86_64 requires ruby(abi) = 0:1.9.1 xmms2-ruby-0.8-8.fc19.x86_64 requires libruby.so.1.9()(64bit) wallaby Done. Vít [1] https://bugzilla.redhat.com/show_bug.cgi?id=922460 [2] https://bugzilla.redhat.com/show_bug.cgi?id=927277 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Tue, Apr 2, 2013 at 6:36 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote: http://dl.dropbox.com/u/1522424/probable-violations-F19.xls That shows: garbage Can you use a non-proprietary format please. http://dl.dropbox.com/u/1522424/probable-violations-F19.csv -- Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2 Apr 2013 13:27:43 + (UTC) Petr Pisar ppi...@redhat.com wrote: On 2013-03-29, seth vidal skvi...@fedoraproject.org wrote: What's Architecture good for? To allow multilib. To install more instances of the same version. And yum ignores Architecture on purpose. But don't tell anybody that. Otherwise he could not claim we do not implement parallel installation. Yum ignores arch? Since when? Maybe you're using the word 'ignores' in a way I'm not familiar with. Yes, I used it a little metaphorically. I don't think you're using 'metaphorically' correctly here. Yum doesn't ignore arch and I think you should stop saying that, no matter what sense of the word 'ignores' you think you're using. yum install foo.i386 does exactly what you think it does. yum install foo installs the bestarch is can find for that pkgname. That's exactly the goal. Yum _understands_ architecture. It allows you to install, upgrade, remove architecteruces independetly, yet it allow to substistute one with another one to meet dependencies. Misusing names does not allow all of that. misusing? Is this, again, another metaphor? Please speak plainly. What do you mean here? Where is the misuse? -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[SOLVED] fedpkg upload errors
Hi, When I tried to run fedpkg upload I got error: Could not execute new_sources: Lookaside failure: (60, Peer's certificate issuer has been marked as not trusted by the user.) This is how I solved it: certutil -d sql:$HOME/.pki/nssdb -A -i \ $HOME/.fedora-server-ca.cert -n 'Fedora Project CA' -t TC,C,C Hope that helps. -- Regards,-- Sir Raorn. --- http://thousandsofhate.blogspot.com/ signature.asc Description: Digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On 2013-03-29, Miloslav Trmač m...@volny.cz wrote: On Fri, Mar 29, 2013 at 3:01 PM, Petr Pisar ppi...@redhat.com wrote: On 2013-03-29, Tomas Mraz tm...@redhat.com wrote: Basically yes. It's call for semantically separeted API identifier. Now you have NEVRA string: Where we have API? Nowhere because Fedora assumes only one version of a package. API should work like Architecture in sense of parallel instalability, but it shouls provide name spacing for EVR string. API itself should define orderding to allow selecting latest package across all builds as already commmentd: Isn't one of the principal problems that lead to calls for transparent multiple version support exactly the _impossibility_ of having an API identifier? Not only. It does not matter if upstream versions API properly or if upstream does it at all. If you do not like `API', use `interface' or `contract' or whatever word you like. People do not demand multiversioning because they can. They demand it because presence of specific version provides specific features. It's up to packagers to define the branches/APIs/slots. (Happy are those whose upstream is version pedantic.) However, other languages don't have an API identifier. Collecting a few Gem requirements from my system: s.add_dependency(%qactivesupport, [= 0]) s.add_dependency(%qactivesupport, [~ 3.0]) s.add_dependency(%qactivesupport, [~ 3.0.0]) s.add_dependency(%qactivesupport, [= 3.2.8]) If this is conjuction, then the set is empty. If this is disjunction, then this is full set. What API identifier would you actually use for rubygem-activesupport? What API identifer would you want to _autogenerate_ for rubygem-activesupport? You'll need API 3.2.8 at which point upgrades start looking as a little meaningless concept. Similarly, maven version ranges also don't lend themselves to the concept of API identifier: version[3.8,4.0)/version I can construct arbitrary overlapping ranges, so a single API identifier won't work. Requires: foo = 3.8 Requires: foo 4.0 Or maybe there are APIs 3.8, 3.9, and 4.0 and we want to express (3.8 or 3.9), but poor RPM does not handle `or'? -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Tue, Apr 02, 2013 at 07:15:29PM +0530, Dhiru Kholia wrote:
On Tue, Apr 2, 2013 at 6:36 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote:
http://dl.dropbox.com/u/1522424/probable-violations-F19.xls
That shows:
garbage
Can you use a non-proprietary format please.
http://dl.dropbox.com/u/1522424/probable-violations-F19.csv
FWIW, the following command produces much better output:
function display {
echo Package: $1 \($2\)
echo Binary: $3 \(mode $8 $9 $10\)
echo NX $4 CANARY $5 RELRO $6 PIE $7
}
export -f display
csvtool drop 1 probable-violations-F19.csv | csvtool call display - | less
like this:
Package: autodir (autodir-0.99.9-15.fc19.x86_64.rpm)
Binary: /usr/sbin/autodir (mode 0100755 daemon autodir0)
NX Enabled CANARY Enabled RELRO Partial PIE Disabled
Although it's not perfect because what you really have is a tree, not
a table.
It would be helpful to have packager names alongside each package too.
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
Orphaning maven-pmd-plugin
Hi, I am orphaning maven-pmd-plugin due to serious hardships when updating, and I don't really need it. It is buildrequired by: ehcache-parent-0:2.3-4.fc19.src ehcache-sizeof-agent-0:1.0.1-4.fc19.src maven-license-plugin-0:1.8.0-13.fc19.src quartz-0:2.1.2-7.fc19.src resteasy-0:2.3.2-9.fc18.src Required by: tuscany-parent-0:2-5.fc19.noarch Associated bugs: https://bugzilla.redhat.com/show_bug.cgi?id=912085 TR -- Tomas Radej tra...@redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XFS and trim
On 4/1/13 5:26 PM, Steven Haigh wrote: On 04/02/2013 12:19 AM, Josef Bacik wrote: On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh net...@crc.id.au wrote: Hi all, Firstly, Please CC me into replies as I'm not subscribed to this list. I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount': ... Can anyone share some insight into this? IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks, Hi Josef, This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above. Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option. I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...). Thanks, -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On 2013-04-02, seth vidal skvi...@fedoraproject.org wrote: On Tue, 2 Apr 2013 13:27:43 + (UTC) Petr Pisar ppi...@redhat.com wrote: Misusing names does not allow all of that. misusing? Is this, again, another metaphor? Please speak plainly. What do you mean here? Where is the misuse? foo1, foo2, foo3 -- there is no ordering in the upgrade path, you cannot say foo2 or newer. From my point of view mangling package names (see scl_utils) is misuse. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2 Apr 2013 14:02:46 + (UTC) Petr Pisar ppi...@redhat.com wrote: Or maybe there are APIs 3.8, 3.9, and 4.0 and we want to express (3.8 or 3.9), but poor RPM does not handle `or'? After reading these and other comments from you, Petr, it seems to me you are not interested in making things better, you just want to complain about how you think rpm is not sufficient for what you seem to think is the most important use case. Since you seem to think you're very well versed in the subject area. I'd recommend you pitch in on rpm and dnf development, rather than just pitching unconstructive criticism at them. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2 Apr 2013 14:16:31 + (UTC) Petr Pisar ppi...@redhat.com wrote: On 2013-04-02, seth vidal skvi...@fedoraproject.org wrote: On Tue, 2 Apr 2013 13:27:43 + (UTC) Petr Pisar ppi...@redhat.com wrote: Misusing names does not allow all of that. misusing? Is this, again, another metaphor? Please speak plainly. What do you mean here? Where is the misuse? foo1, foo2, foo3 -- there is no ordering in the upgrade path, you cannot say foo2 or newer. From my point of view mangling package names (see scl_utils) is misuse. There's no ordering b/c those pkgs are not intended to be version-compared to each other. That is, in fact, the goal. If you GOAL is to avoid version comparisons then it is hardly misuse. You should go back and read James' example using shells, it might be easier to understand. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XFS and trim
On 03/04/13 01:08, Eric Sandeen wrote: On 4/1/13 5:26 PM, Steven Haigh wrote: On 04/02/2013 12:19 AM, Josef Bacik wrote: On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh net...@crc.id.au wrote: Hi all, Firstly, Please CC me into replies as I'm not subscribed to this list. I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount': ... Can anyone share some insight into this? IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks, Hi Josef, This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above. Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option. Thanks for the reply Eric. I believe it would be helpful if this was documented. I was expecting it to work the same way as ext4 - being a simple remount would enable the discard option. Once that didn't work - and especially as I didn't get an error in either the syslog or returned from the command, I was starting to think it was a bug in the implementation of TRIM in XFS. I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...). I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look. The wiki page[1] for XFS does state that XFS supports TRIM - and it mentions the changes to /etc/fstab to enable it. It doesn't however mention that it needs to be on the initial mount - or that a remount will not enable it. The best of both worlds would be to have it output to the dmesg - or even fail the mount command (if that is an option?) just like ext4 would if you supply a bogus option set. 1: http://xfs.org/index.php/FITRIM/discard -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
ARM Secret Docoder Ring Wiki Page
Good day all, At FUDCon we discussed the creation of a 'Secret Decoder Ring' document that would help those new to the ARM world to quickly become familiar with the ongoing work and ease the process of jumping in. A draft of the document has been posted: https://fedoraproject.org/wiki/Architectures/ARM/Secret_Decoder_Ring Please take a few moments to have a look, and feel free to contribute or provide feedback on any areas that may need more fleshing out or have yet to have text added. There is a link at the top of the page to the original document created at FUDCon for reference. Thanks, Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XFS and trim
On 4/2/13 9:30 AM, Ric Wheeler wrote: On 04/02/2013 10:26 AM, Steven Haigh wrote: On 03/04/13 01:08, Eric Sandeen wrote: On 4/1/13 5:26 PM, Steven Haigh wrote: On 04/02/2013 12:19 AM, Josef Bacik wrote: On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh net...@crc.id.au wrote: Hi all, Firstly, Please CC me into replies as I'm not subscribed to this list. I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount': ... Can anyone share some insight into this? IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks, Hi Josef, This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above. Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option. Thanks for the reply Eric. I believe it would be helpful if this was documented. I was expecting it to work the same way as ext4 - being a simple remount would enable the discard option. Once that didn't work - and especially as I didn't get an error in either the syslog or returned from the command, I was starting to think it was a bug in the implementation of TRIM in XFS. I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...). I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look. The wiki page[1] for XFS does state that XFS supports TRIM - and it mentions the changes to /etc/fstab to enable it. It doesn't however mention that it needs to be on the initial mount - or that a remount will not enable it. The best of both worlds would be to have it output to the dmesg - or even fail the mount command (if that is an option?) just like ext4 would if you supply a bogus option set. 1: http://xfs.org/index.php/FITRIM/discard Is there any reason that discard cannot be enabled on remount like it is for other file systems? And disabled on remount for completeness? Discard should be one of the easier ones to change on remount; things like quota are tougher. I was talking w/ Dave about this just yesterday, and he pointed out that we might need to serialize access to some of the things that would get changed on a remount. BTW Steven - we often recommend against runtime trim, and suggest fstrim instead, for performance reasons. Just something to maybe keep in mind and experiment with. -Eric Seems like something that we would definitely want to be consistent across file systems on, Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 947489] New: Please revert the unbundling of inc::Module::Install, at least when bootstrapping
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947489 Bug ID: 947489 Summary: Please revert the unbundling of inc::Module::Install, at least when bootstrapping Product: Fedora Version: rawhide Component: perl-CPANPLUS Severity: unspecified Priority: unspecified Assignee: ppi...@redhat.com Reporter: p...@city-fan.org QA Contact: extras...@fedoraproject.org CC: perl-de...@lists.fedoraproject.org, ppi...@redhat.com Category: --- perl-CPANPLUS includes the inc::Module::Install needed to build it but this is removed and a buildreq of perl(inc::Module::Install) is used instead. However, perl-Module-Install itself has a dependency on perl(CPANPLUS::Backend), which is provided by perl-CPANPLUS, thus creating a build dependency loop. This could be avoided by reverting the unbundling of inc::Module::Install from perl-CPANPLUS. -- 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=fKMZFP5DVCa=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: Expanding the list of Hardened Packages
$ gcc -m32 -fPIE -O -S foo.c $ cat foo.s # edited for brevity foo: # 25 bytes; about 15 cycles (incl. 3*3 cycles data cache fetch latency) call__x86.get_pc_thunk.cx addl$_GLOBAL_OFFSET_TABLE_, %ecx movl4(%esp), %eax movla@GOT(%ecx), %edx movl%eax, (%edx,%eax,4) ret Yes, but... Am I right in thinking that a page containing the above can be shared, ... Yes. '_GLOBAL_OFFSET_TABLE_' and 'a@GOT' both are constants whose value is established by the static linker /bin/ld and unchanged for every subsequent execve(). The final relocation of _GLOBAL_OFFSET_TABLE_ is performed during execution by the 'addl' using the execution-time base address returned by __x86.get_pc_thunk.cx. The final relocation for the address of a[] is performed at the start of execution by ld-linux changing the value contained in the GOT. $ gcc -m32 -O -S foo.c $ cat foo.s # edited for brevity foo: # 12 bytes; about 6 cycles (incl. 1*3 cycles data cache fetch latency) movl4(%esp), %eax movl%eax, a(,%eax,4) ret $ ... but a page containing this cannot because it must be relocated prior to execution? For a main program in normal usage where 'a' must be defined in the target of execve [else static linking fails], then that page _can_ be shared, and is shared. The relocation occurs at static link time. If 'a' remains undefined at the end of static linking, or if 'a' is known to reside in some shared library, then yes, the address must be relocated at the time of execution, and therefore the page cannot be shared. For a shared library, that code is not even -fPIC, so it won't work on many platforms, although i686 allows it. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XFS and trim
On 04/02/2013 10:26 AM, Steven Haigh wrote: On 03/04/13 01:08, Eric Sandeen wrote: On 4/1/13 5:26 PM, Steven Haigh wrote: On 04/02/2013 12:19 AM, Josef Bacik wrote: On Sat, Mar 30, 2013 at 9:38 PM, Steven Haigh net...@crc.id.au wrote: Hi all, Firstly, Please CC me into replies as I'm not subscribed to this list. I'm trying to confirm that Fedora 18 has enabled trim for XFS filesystems. I have added discard to the mount options in /etc/fstab - however I do not see it when looking at the output of 'mount': ... Can anyone share some insight into this? IIRC you have to rebuild your initrd so it picks up the new fstab mount options for /, the other options is you should be able to do mount -o remount,discard /. Thanks, Hi Josef, This was the basis of my query - even after a remount with the discard option, 'discard' still wasn't present in the options - as seen by the mount line quoted above. Sorry I didn't see this earlier. Josef is right; discard is not a remountable option on xfs, unfortunately (only inode64 and barrier options are remountable today). So you could either put the option in the rootflags= kernel commandline parameter, or rebuild the initrd after adding it to fstab as Josef suggested so that it's initially mounted with the option. Thanks for the reply Eric. I believe it would be helpful if this was documented. I was expecting it to work the same way as ext4 - being a simple remount would enable the discard option. Once that didn't work - and especially as I didn't get an error in either the syslog or returned from the command, I was starting to think it was a bug in the implementation of TRIM in XFS. I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...). I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look. The wiki page[1] for XFS does state that XFS supports TRIM - and it mentions the changes to /etc/fstab to enable it. It doesn't however mention that it needs to be on the initial mount - or that a remount will not enable it. The best of both worlds would be to have it output to the dmesg - or even fail the mount command (if that is an option?) just like ext4 would if you supply a bogus option set. 1: http://xfs.org/index.php/FITRIM/discard Is there any reason that discard cannot be enabled on remount like it is for other file systems? And disabled on remount for completeness? Seems like something that we would definitely want to be consistent across file systems on, Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XFS and trim
On 03/04/13 01:46, Eric Sandeen wrote: BTW Steven - we often recommend against runtime trim, and suggest fstrim instead, for performance reasons. Just something to maybe keep in mind and experiment with. Thats ok - this isn't for a high-performance system - this is just me messing around on my EEEPC with a 64Gb SSD. Its better for me to have TRIM in runtime because anything (and I mean anything!) would beat the stock 5400rpm drive that was originally in it - that and it isn't on 24/7 to run fstrim in cron - which is probably the preferred method :) I've used XFS on some large (by my standards, probably not by yours) filesystems over the years and really like it - seeing Fedora 18 supported XFS as root, I though I'd give it a try. There is no real technical reason other than 'because I can' :) -- Steven Haigh Email: net...@crc.id.au Web: https://www.crc.id.au Phone: (03) 9001 6090 - 0412 935 897 Fax: (03) 8338 0299 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Fedora 19 Alpha Change freeze
- Forwarded Message - From: Dennis Gilmore den...@ausil.us To: devel-annou...@lists.fedoraproject.org Sent: Tuesday, April 2, 2013 4:40:41 AM Subject: Fedora 19 Alpha Change freeze Hi all, as the Fedora 19 schedule[1] states the Alpha change freeze is upon us. As we are now at the change freeze bodhi has been enabled for f19 now. it means all builds will now need an update cretaed and as we are at Alpha freeze only accepted exceptions[2] will be allowed in. we are at the pre beta stage of release, so the Pre-beta[3] stage of the updates policy applies Regards Dennis [1] http://fedorapeople.org/groups/schedule/f-19/f-19-devel-tasks.html [2] http://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [3] http://fedoraproject.org/wiki/Updates_Policy#Pre_Beta ___ 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
CANCELED: Wednesday's FESCo Meeting (2012-04-03)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There are currently no tickets in the FESCo Trac instance that require discussion tomorrow. After discussion with several other FESCo members in #fedora-devel, we agreed to cancel this week's meeting unless something urgent comes up. If you feel that you have a topic that requires FESCo attention tomorrow, please reply to this email thread. Thank you. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFbHcgACgkQeiVVYja6o6MLUwCeJNjNpeOFlSQI9iCynpwFKkJw KH0An1spk958mSnQO9RXJTQmTFxE8TPO =7t8v -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: XFS and trim
On 4/2/13 9:26 AM, Steven Haigh wrote: On 03/04/13 01:08, Eric Sandeen wrote: snip I wonder if we should add something to the remount path to printk when a non-remountable option is encountered; I might look into that, otherwise it's a little surprising (although semi-obvious when the problem doesn't show up in /prcoc/mounts...). I think this is probably the best way to handle things. The first thing I did was to look at the return code from mount (which returned 0 - ie success), then dmesg, then /var/log/messages. As I found nothing, I had no hints on where to look. FWIW, there is some history here w/ returning 0/success for these options: /* * Logically we would return an error here to prevent * users from believing they might have changed * mount options using remount which can't be changed. * * But unfortunately mount(8) adds all options from * mtab and fstab to the mount arguments in some cases * so we can't blindly reject options, but have to * check for each specified option if it actually * differs from the currently set option and only * reject it if that's the case. * * Until that is implemented we return success for * every remount request, and silently ignore all * options that we can't actually change. */ #if 0 xfs_info(mp, mount option \%s\ not supported for remount\n, p); return -EINVAL; #else break; #endif Not great, but there it is. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using Fedora for Gnome development...
On Tue, Apr 02, 2013 at 09:28:12PM +0800, Mathieu Bridon wrote: You can perfectly well have Python 2 and 3 coexisting on the same Fedora, and use either in your projects. The packages are made to be installed in parallel, and there shouldn't be any conflicts. Many people are developing applications in Python 2 or Python 3 on the same Fedora machine (myself included). Unless you're hitting a bug, of course. Could you give more details on what the problem actually is? Sure thing. What I'm hitting is a problem in my day job projects (Qpid and Proton). In both cases we have core code written in C++ (Qpid) and C (Proton) and provide language bindings via Swig. We use Cmake as our build system. When python3 is installed then, with both projects, Cmake finds Python 3. But when the build environment generates the Python language bindings it's consistently failing to link the libpython2.7 library, and the build fails. When I uninstall python3, Cmake finds Python 2.7 and links it in correctly and all is good. -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.multiply.com/ What do you care what people think, Mr. Feynman? pgp6c2TE9j_h3.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
How do *you* use Fedora?
Hello, The docs team has begun assembling release notes for Fedora 19, and I've been thinking over hardware requirements. Historically, we have cited the CPU, storage, and especially memory requirements for the default installation - a basic GNOME desktop. I'd like to reexamine that practice, with input from the development community. Fedora is too versatile a product to document so narrowly. A few considerations come immediately to mind, but please don't limit yourself to the examples: Modern composited desktops like GNOME and KDE need better graphics hardware than XFCE or MATE. Headless servers would benefit from better NICs or storage controllers, but not require them. Purpose driven virtual machines clearly need fewer resources than the machine that hosts them. I'm considering system specs at this point, but establishing the roles deployed might aid in targeting more comprehensive documentation. Beyond a basic desktop, what use cases would you like to see us represent? -- Pete Travis - Fedora Docs Project Leader - 'randomuser' on freenode - immanetize at fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using Fedora for Gnome development...
On Tue, 2013-04-02 at 15:31 -0400, Darryl L. Pierce wrote: When python3 is installed then, with both projects, Cmake finds Python 3. This seems like either a bug in Cmake or your project (not sure which) - if it's possible to explicitly specify that you want Python 2, then you should be doing so. Likewise, if a project wants Python 3, you should also explicitly say so, at least in the build configuration (spec file, bitbake recipe, debian/rules etc.). Basically while it's sometimes sane for a component to auto-detect from the environment which Python to use, you should generally configure it explicitly to use whichever one you want. See also: https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00014.html Where the conclusion for GNOME was that modules should accept --with-python to specify exactly which Python they want. See also http://pkgs.fedoraproject.org/cgit/pygobject3.git/tree/pygobject3.spec#n163 which is accomplishing this in a slightly different way. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote: On Fri, Mar 29, 2013 at 10:43 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Mar 29, 2013 at 10:08:37PM +0530, Dhiru Kholia wrote: 1. Hardening flags should be turned on (by default) for all packages which are at comparatively more risk of being exploited or which meet some well-defined criteria (suggestions welcome). Is there somewhere which describes what to do / what flags to enable? http://wiki.debian.org/Hardening describes the various hardening flags. _hardened_build rpm spec macro can be used to harden a package. For an example, see http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec This flag is overly aggressive. We have a list of programs that need PIE enabled and doing more isn't necessarily constructive. What would be nice is if the autotools got some macros to detect PIE and RELRO support in gcc so that its easy to add to CFLAGS and LDFLAGS so that it can be applied more precisely. -Steve -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
I'm WAY out on the bell curve... I have two PCs. One of them, the one I sit in front of, has four monitors (on one Radeon HD card), video capture and playback, digital and analog audio (digital goes to a surround system receiver, analog to gaming headphones), an SSD plus a dual-3Tb raid1 all in a hot-swap bay, and a bunch of other stuff (mostly usb - lab equipment, scanner, two android devices, etc). It's a six-core i7 with 24 GB of RAM, and typically about half the RAM is in active use (the rest is for cache). I have some guest OSs but don't run them unless I need to, but the PC itself is up 24/7. I run fvwm2 across all monitors as one giant screen (the main screen is not the leftmost screen, and eventually won't be the topmost one either), and assign two virtual desktops to the local PC. I tried gaming under a composited desktop but the FPS dropped so compositing was dropped too. The other two virtual desktops are assigned to my other PC, which sits in the basement and only talks over X and ssh. I do *not* use any ramdisks or tmpfs. I also remove abrt as it takes too long to run if anything crashes (they tend to be BIG crashes). This setup is used for software development, gaming, EDA, email (10 mailboxes to monitor), web, and as a home (er, office :) theater. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using Fedora for Gnome development...
On Tue, Apr 02, 2013 at 03:50:26PM -0400, Colin Walters wrote: On Tue, 2013-04-02 at 15:31 -0400, Darryl L. Pierce wrote: When python3 is installed then, with both projects, Cmake finds Python 3. This seems like either a bug in Cmake or your project (not sure which) - if it's possible to explicitly specify that you want Python 2, then you should be doing so. Likewise, if a project wants Python 3, you should also explicitly say so, at least in the build configuration (spec file, bitbake recipe, debian/rules etc.). Basically while it's sometimes sane for a component to auto-detect from the environment which Python to use, you should generally configure it explicitly to use whichever one you want. See also: https://mail.gnome.org/archives/desktop-devel-list/2012-November/msg00014.html Where the conclusion for GNOME was that modules should accept --with-python to specify exactly which Python they want. See also http://pkgs.fedoraproject.org/cgit/pygobject3.git/tree/pygobject3.spec#n163 which is accomplishing this in a slightly different way. I found the problem, but it seems to be in Cmake. find_package(PythonInterp 2.7 REQUIRED) works as expected and finds Python 2.7. However: find_package(PythonLibs 2.7 REQUIRED) _always_ comes back with the Python 3 library instead of the 2.7 library. -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.multiply.com/ What do you care what people think, Mr. Feynman? pgpZrfsS4DQUS.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
On Tue, Apr 02, 2013 at 01:47:48PM -0600, Pete Travis wrote: I'm considering system specs at this point, but establishing the roles deployed might aid in targeting more comprehensive documentation. Beyond a basic desktop, what use cases would you like to see us represent? Cloud guest, please. -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On 31/03/13 08:11 AM, Richard W.M. Jones wrote: However prelink does reduce the effectiveness of ASLR (a bit). See http://lwn.net/Articles/341440/ and follow-up conversation. Ignoring the silly stuff, it does seem that this is Yet Another Reason Prelink Is Bad, and we seem to keep bumping up against those. It does rather seem like we should consider just killing it, at least by default. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
On 02/04/13 02:26 PM, Matthew Miller wrote: On Tue, Apr 02, 2013 at 01:47:48PM -0600, Pete Travis wrote: I'm considering system specs at this point, but establishing the roles deployed might aid in targeting more comprehensive documentation. Beyond a basic desktop, what use cases would you like to see us represent? Cloud guest, please. What kind of cloud? What kind of guest? I'm worried that this will turn into a very large and amorphous effort. Trying to pin down 'typical Fedora use cases' seems rather like trying to box a cloud. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
Am 03.04.2013 00:18, schrieb Adam Williamson: On 31/03/13 08:11 AM, Richard W.M. Jones wrote: However prelink does reduce the effectiveness of ASLR (a bit). See http://lwn.net/Articles/341440/ and follow-up conversation. Ignoring the silly stuff, it does seem that this is Yet Another Reason Prelink Is Bad, and we seem to keep bumping up against those. It does rather seem like we should consider just killing it, at least by default. +1 * i see NO NOTICEABLE better performance in any environment * it does all the things which was a pseudo reason for offline updates * it makes intrusion detection only working with bad hacks * it is lowering security for zero benefit signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: package, package2, package3 naming-with-version exploit
On Tue, 2013-04-02 at 14:16 +, Petr Pisar wrote: On 2013-04-02, seth vidal skvi...@fedoraproject.org wrote: On Tue, 2 Apr 2013 13:27:43 + (UTC) Petr Pisar ppi...@redhat.com wrote: Misusing names does not allow all of that. misusing? Is this, again, another metaphor? Please speak plainly. What do you mean here? Where is the misuse? foo1, foo2, foo3 -- there is no ordering in the upgrade path, you cannot say foo2 or newer. From my point of view mangling package names (see scl_utils) is misuse. To re-iterate what I wrote before, if you want to be able to say foo2 or foo3 there is a defined mechanism for that ... all packages you want to require use Provide: foo-api-2-or-higher and you require that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GSoC
Hi all, My name is Ruben Guerra (biker on Freenode) and I have been a Fedora ambassador for a year, but I am also a student, and I would like to participate on the GSoC working for Fedora. I know python (and also I have knowledge of the django framework), java, C, assembly and some PHP. I also know QT. But I can learn any other language/tool that may be needed for a project (: So I am looking if someone is willing to mentor, and also ideas on what does the devel team may need that I could work on. Any help is appreciated (: Thanks a lot! -- Rubén Guerra Marín rugebi...@fedoraproject.org http://fedoraproject.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Tue, 2 Apr 2013, Adam Williamson wrote: Date: Tue, 02 Apr 2013 15:18:55 -0700 From: Adam Williamson awill...@redhat.com Reply-To: Development discussions related to Fedora devel@lists.fedoraproject.org To: devel@lists.fedoraproject.org Subject: Re: Expanding the list of Hardened Packages On 31/03/13 08:11 AM, Richard W.M. Jones wrote: However prelink does reduce the effectiveness of ASLR (a bit). See http://lwn.net/Articles/341440/ and follow-up conversation. Ignoring the silly stuff, it does seem that this is Yet Another Reason Prelink Is Bad, and we seem to keep bumping up against those. It does rather seem like we should consider just killing it, at least by default. At this point I have the feeling that Prelink is a cargo cult which we keep around to appease the Airplane Gods. -- Stephen John Smoogen RHCE: 805299440800213 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
It does rather seem like we should consider just killing it [prelink], at least by default. Prelinking shortens the time between execve() and first useful output. A prelinked module reduces time spent in ld-linux, and increases sharing of pages (which reduces time spent in kernel duplicating copy-on-write pages.) The savings are *visible* when invoking an interactive GUI program that has dozens of shared libraries, or when several hundred smaller executables are invoked each second, such as some 'make' clouds, etc. Some systems want those savings, and are willing to pay with slightly less protection via reduced ASLR. Some administrators compensate by running a full prelink daily, and a partial prelink of hot modules (glibc, ...) a few times during the day, even as often as hourly; and with parameters to reduce interference with modules which are not being [re-]prelinked during the current run. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: How do *you* use Fedora?
On Tue, Apr 02, 2013 at 03:28:21PM -0700, Adam Williamson wrote: I'm considering system specs at this point, but establishing the roles deployed might aid in targeting more comprehensive documentation. Beyond a basic desktop, what use cases would you like to see us represent? Cloud guest, please. What kind of cloud? What kind of guest? I'm worried that this will turn into a very large and amorphous effort. Sure; let's start concrete -- Amazon EC2, starting at M1 Small. If we can make it run nicely on Micro instances (and I don't see why not), so much the better. Trying to pin down 'typical Fedora use cases' seems rather like trying to box a cloud. Maybe we could at least try to describe the cloud a bit, though? That one looks like a fluffy bunny -- Matthew Miller ☁☁☁ Fedora Cloud Architect ☁☁☁ mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Expanding the list of Hardened Packages
On Tue, 02 Apr 2013 16:50:33 -0700 John Reiser jrei...@bitwagon.com wrote: It does rather seem like we should consider just killing it [prelink], at least by default. Prelinking shortens the time between execve() and first useful output. A prelinked module reduces time spent in ld-linux, and increases sharing of pages (which reduces time spent in kernel duplicating copy-on-write pages.) The savings are *visible* when invoking an interactive GUI program that has dozens of shared libraries, or when several hundred smaller executables are invoked each second, such as some 'make' clouds, etc. I'm not so sure they are... perhaps it's time for another round of 'how fast does libreoffice start when prelinked vs not' ? Some systems want those savings, and are willing to pay with slightly less protection via reduced ASLR. Some administrators compensate by running a full prelink daily, and a partial prelink of hot modules (glibc, ...) a few times during the day, even as often as hourly; and with parameters to reduce interference with modules which are not being [re-]prelinked during the current run. Indeed. Also, some administrators remove prelink and do not use it on any of there systems. (Like say, Fedora Infrastructure, or all my home machines). kevin 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
Am 03.04.2013 01:50, schrieb John Reiser: It does rather seem like we should consider just killing it [prelink], at least by default. Prelinking shortens the time between execve() and first useful output in theory A prelinked module reduces time spent in ld-linux, and increases sharing of pages (which reduces time spent in kernel duplicating copy-on-write pages.) The savings are *visible* when invoking an interactive GUI program that has dozens of shared libraries, or when several hundred smaller executables are invoked each second, such as some 'make' clouds, etc. not noticeable compared with the security flaws Some systems want those savings, and are willing to pay with slightly less protection via reduced ASLR. then THIS SYSTEMS shoudk install prelink but not install it AS DEFAULT Some administrators compensate by running a full prelink daily, and a partial prelink of hot modules (glibc, ...) a few times during the day, even as often as hourly; and with parameters to reduce interference with modules which are not being [re-]prelinked during the current run fine they should do what they want but as DEFAULT anything which beats ASLR is UNACCEPTABLE these days signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: CANCELED: Wednesday's FESCo Meeting (2012-04-03)
On Tue, Apr 2, 2013 at 11:34 PM, Stephen Gallagher sgall...@redhat.com wrote: There are currently no tickets in the FESCo Trac instance that require discussion tomorrow. After discussion with several other FESCo members in #fedora-devel, we agreed to cancel this week's meeting unless something urgent comes up. If you feel that you have a topic that requires FESCo attention tomorrow, please reply to this email thread. https://fedorahosted.org/fesco/ticket/1104 This one requires discussion. -- Dhiru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 947238] perl-DateTime-1.01 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947238 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|st...@silug.org |psab...@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=FKkgaSZV98a=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 DateTime-1.01.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DateTime: 55249047e60b84d5b398fc78c00368cb DateTime-1.01.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-DateTime] 1.01 bump
commit 619c758685f68527029682f9ec715775ce11c520
Author: Petr Šabata con...@redhat.com
Date: Tue Apr 2 09:18:44 2013 +0200
1.01 bump
.gitignore |1 +
perl-DateTime.spec | 18 +++---
sources|2 +-
3 files changed, 17 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 659ce15..8fb00a1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ DateTime-TimeZone-1.10.tar.gz
/DateTime-TimeZone-1.35.tar.gz
/DateTime-0.77.tar.gz
/DateTime-0.78.tar.gz
+/DateTime-1.01.tar.gz
diff --git a/perl-DateTime.spec b/perl-DateTime.spec
index 59b4187..c98b64d 100644
--- a/perl-DateTime.spec
+++ b/perl-DateTime.spec
@@ -1,28 +1,37 @@
Name: perl-DateTime
Epoch: 2
-Version:0.78
-Release:2%{?dist}
+Version:1.01
+Release:1%{?dist}
Summary:Date and time object
License:Artistic 2.0
Group: Development/Libraries
URL:http://search.cpan.org/dist/DateTime/
Source0:
http://www.cpan.org/authors/id/D/DR/DROLSKY/DateTime-%{version}.tar.gz
+BuildRequires: perl
BuildRequires: perl(Module::Build)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time:
BuildRequires: perl(base)
BuildRequires: perl(Carp)
BuildRequires: perl(constant)
BuildRequires: perl(DateTime::Locale) = 0.41
BuildRequires: perl(DateTime::TimeZone) = 1.09
+BuildRequires: perl(integer)
+BuildRequires: perl(overload)
BuildRequires: perl(Params::Validate) = 0.76
+BuildRequires: perl(POSIX)
BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Try::Tiny)
+BuildRequires: perl(vars)
BuildRequires: perl(XSLoader)
# Tests:
+BuildRequires: perl(Test::Fatal)
BuildRequires: perl(Test::More) = 0.88
+BuildRequires: perl(utf8)
# Optional tests:
# circular dependency - perl(DateTime::Format::Strptime) = 1.2000
BuildRequires: perl(Storable)
-BuildRequires: perl(Test::Fatal)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
Requires: perl(XSLoader)
@@ -64,6 +73,9 @@ find %{buildroot} -type f -name '*.bs' -size 0 -exec rm -f {}
\;
%{_mandir}/man3/*
%changelog
+* Tue Apr 02 2013 Petr Šabata con...@redhat.com - 2:1.01-1
+- 1.01 bump
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2:0.78-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 10450c5..94d02f6 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-9d71a13933e3afc55c2c54202d40ae13 DateTime-0.78.tar.gz
+55249047e60b84d5b398fc78c00368cb DateTime-1.01.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-DateTime/f19] 1.01 bump
Summary of changes: 619c758... 1.01 bump (*) (*) 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 947238] perl-DateTime-1.01 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947238 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-DateTime-1.01-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-04-02 03:54:02 -- 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=h9WPvhSt9ta=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 946889] perl-Text-CSV_XS-0.97 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=946889 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com Assignee|mmasl...@redhat.com |psab...@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=7HZ5HFkKS1a=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 Text-CSV_XS-0.97.tgz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-Text-CSV_XS: 0661ffaabc368338a4c001d71fe0551e Text-CSV_XS-0.97.tgz -- 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-Text-CSV_XS] 0.97 bump, performance enhancement
commit c59d3546a079579e31907a3268c95c907d43f966
Author: Petr Šabata con...@redhat.com
Date: Tue Apr 2 10:11:18 2013 +0200
0.97 bump, performance enhancement
.gitignore|1 +
perl-Text-CSV_XS.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e02d036..5dc94ce 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,3 +19,4 @@ Text-CSV_XS-0.72.tgz
/Text-CSV_XS-0.94.tgz
/Text-CSV_XS-0.95.tgz
/Text-CSV_XS-0.96.tgz
+/Text-CSV_XS-0.97.tgz
diff --git a/perl-Text-CSV_XS.spec b/perl-Text-CSV_XS.spec
index 5aed1af..34dc03a 100644
--- a/perl-Text-CSV_XS.spec
+++ b/perl-Text-CSV_XS.spec
@@ -1,5 +1,5 @@
Name: perl-Text-CSV_XS
-Version:0.96
+Version:0.97
Release:1%{?dist}
Summary:Comma-separated values manipulation routines
Group: Development/Libraries
@@ -67,6 +67,9 @@ make test %{?_smp_mflags}
%{_mandir}/man3/*.3pm*
%changelog
+* Tue Apr 02 2013 Petr Šabata con...@redhat.com - 0.97-1
+- 0.97 bump, performance enhancement
+
* Wed Mar 27 2013 Petr Šabata con...@redhat.com - 0.96-1
- 0.96 bump
diff --git a/sources b/sources
index f776709..e4a1358 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-27d5c4aacf34791824a1826f93015c3d Text-CSV_XS-0.96.tgz
+0661ffaabc368338a4c001d71fe0551e Text-CSV_XS-0.97.tgz
--
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-Text-CSV_XS/f19] 0.97 bump, performance enhancement
Summary of changes: c59d354... 0.97 bump, performance enhancement (*) (*) 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 919810] automake seems to depend on perl-Thread-Queue but perl-Thread-Queue is not required by automake
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=919810 Pavel Raiskup prais...@redhat.com changed: What|Removed |Added CC||cw...@alumni.drew.edu, ||iarn...@gmail.com, ||jples...@redhat.com, ||ka...@ucw.cz, ||lkund...@v3.sk, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ppi...@redhat.com, ||psab...@redhat.com, ||rc040...@freenet.de, ||tcall...@redhat.com Component|rpm |perl Assignee|packaging-team-maint@redhat |mmasl...@redhat.com |.com| --- Comment #5 from Pavel Raiskup prais...@redhat.com --- Based on bug #924938, it seems that this should be assigned to perl package probably .. Pavel -- 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=5wLYt32oAxa=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 919810] automake seems to depend on perl-Thread-Queue but perl-Thread-Queue is not required by automake
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=919810
Paul Howarth p...@city-fan.org changed:
What|Removed |Added
CC||p...@city-fan.org,
||phra...@redhat.com
Component|perl|automake
Assignee|mmasl...@redhat.com |prais...@redhat.com
--- Comment #6 from Paul Howarth p...@city-fan.org ---
This issue is unrelated to Bug #924938.
The perl dependency generator does not pick up this requirement because
Thread::Queue is only required conditionally:
if ($perl_threads)
{
require threads;
import threads;
require Thread::Queue;
import Thread::Queue;
}
However, since Fedora's perl is built with threads, in practice it's always
needed. The correct fix has already been added to the automake package, namely:
Requires: perl(Thread::Queue)
However, the same applies to the threads module, which should also be
required:
Requires: perl(threads)
--
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=8qv4imlwIha=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 929404] perl-CPAN-Mini-1.111012 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=929404 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=kTbuOgErw6a=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.111012.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-CPAN-Mini: 2a1085a15e09d77e885db750472793e3 CPAN-Mini-1.111012.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.111012 bump
commit 966132ee7ca81c72c96cce631608dfb4df9c2e11
Author: Petr Písař ppi...@redhat.com
Date: Tue Apr 2 12:43:06 2013 +0200
1.111012 bump
.gitignore |1 +
perl-CPAN-Mini.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9c85bca..88023a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -4,3 +4,4 @@ CPAN-Mini-1.100630.tar.gz
/CPAN-Mini-1.111009.tar.gz
/CPAN-Mini-1.111010.tar.gz
/CPAN-Mini-1.111011.tar.gz
+/CPAN-Mini-1.111012.tar.gz
diff --git a/perl-CPAN-Mini.spec b/perl-CPAN-Mini.spec
index b760cb9..492d0e0 100644
--- a/perl-CPAN-Mini.spec
+++ b/perl-CPAN-Mini.spec
@@ -1,6 +1,6 @@
Name: perl-CPAN-Mini
Summary:Create a minimal mirror of CPAN
-Version:1.111011
+Version:1.111012
Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
@@ -8,6 +8,7 @@ Source0:
http://search.cpan.org/CPAN/authors/id/R/RJ/RJBS/CPAN-Mini-%{ver
URL:http://search.cpan.org/dist/CPAN-Mini/
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(Carp)
BuildRequires: perl(Compress::Zlib) = 1.20
BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
@@ -40,7 +41,6 @@ make %{?_smp_mflags}
%install
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} +
-find %{buildroot} -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} %{buildroot}/*
%check
@@ -53,6 +53,9 @@ make test
%{_mandir}/man[13]/*
%changelog
+* Tue Apr 02 2013 Petr Pisar ppi...@redhat.com - 1.111012-1
+- 1.111012 bump
+
* Fri Feb 08 2013 Petr Šabata con...@redhat.com - 1.111011-1
- 1.111011 bump
diff --git a/sources b/sources
index 4667dc7..a21afa2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2416aab2ec0a5ca0ee5217c9ab2a31d4 CPAN-Mini-1.111011.tar.gz
+2a1085a15e09d77e885db750472793e3 CPAN-Mini-1.111012.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 929404] perl-CPAN-Mini-1.111012 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=929404 --- Comment #1 from Petr Pisar ppi...@redhat.com --- Fixes internal test suite. Suitable for F≥19. -- 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=pSiazo8AIKa=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
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
Broken dependencies: perl-Bio-SamTools
perl-Bio-SamTools has broken dependencies in the rawhide 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-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide 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
[Bug 947238] perl-DateTime-1.01 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947238 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|CLOSED |ASSIGNED CC||ppi...@redhat.com Resolution|RAWHIDE |--- Keywords||Reopened --- Comment #1 from Petr Pisar ppi...@redhat.com --- In my opinion this release should go to all Fedoras. First this is pure bug-fix release, second this package delivers leap seconds calendar, so it should be kept up-to-date as much as possible. Please put this version into Fedora 18 and 17. -- 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=gaQozpzLPCa=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 926018] perl-DBI-1.625 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=926018 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|mmasl...@redhat.com |psab...@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=ydso6xyzW5a=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-DateTime/f18] (2 commits) ...1.01 bump
Summary of changes: 4558602... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) 619c758... 1.01 bump (*) (*) 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-DateTime/f17] (8 commits) ...Resolve merge conflicts
Summary of changes: 1dd7b46... Perl 5.16 rebuild (*) 7c9fdc7... - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass (*) 50167b2... 0.77 bump (*) 519fa2c... 0.78 bump (*) ef7b982... fix epoch back to 2 (*) 4558602... - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass (*) 619c758... 1.01 bump (*) a811fa9... Resolve merge conflicts (*) 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-DateTime/f17: 8/8] Resolve merge conflicts
commit a811fa9f513bda9463cb9d26202d5abfb9357e75 Merge: 6ffafd9 619c758 Author: Petr Šabata con...@redhat.com Date: Tue Apr 2 13:50:08 2013 +0200 Resolve merge conflicts .gitignore | 18 +- perl-DateTime.spec | 25 +++-- sources|2 +- 3 files changed, 25 insertions(+), 20 deletions(-) --- diff --cc .gitignore index 659ce15,8fb00a1..70b9321 --- a/.gitignore +++ b/.gitignore @@@ -1,17 -1,18 +1,1 @@@ --DateTime-Locale-0.45.tar.gz --DateTime-0.53.tar.gz --DateTime-TimeZone-1.10.tar.gz --/DateTime-0.63.tar.gz --/DateTime-TimeZone-1.22.tar.gz --/DateTime-0.66.tar.gz --/DateTime-Locale-0.45.tar.gz --/DateTime-TimeZone-1.26.tar.gz --/DateTime-TimeZone-1.31.tar.gz --/DateTime-TimeZone-1.32.tar.gz --/DateTime-TimeZone-1.33.tar.gz --/DateTime-0.69.tar.gz --/DateTime-TimeZone-1.34.tar.gz --/DateTime-0.70.tar.gz --/DateTime-TimeZone-1.35.tar.gz --/DateTime-0.77.tar.gz --/DateTime-0.78.tar.gz + /DateTime-1.01.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 947238] perl-DateTime-1.01 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947238 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-1.01-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/perl-DateTime-1.01-1.fc18 -- 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=FGj1Vthtp8a=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 947238] perl-DateTime-1.01 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947238 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-DateTime-1.01-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/perl-DateTime-1.01-1.fc17 -- 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=jFhYQfWMdHa=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
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
File DBI-1.625.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-DBI: b0521be412faff4ec8d511cd5f3f6a31 DBI-1.625.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-DBI] 1.625 bump, perl5.17 fixes
commit cf8eda6f3bd1a28d50ab5bcd19501fe670634149
Author: Petr Šabata con...@redhat.com
Date: Tue Apr 2 14:15:33 2013 +0200
1.625 bump, perl5.17 fixes
.gitignore|1 +
perl-DBI.spec | 23 ---
sources |2 +-
3 files changed, 22 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9cde910..8488897 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ DBI-1.613.tar.gz
/DBI-1.620.tar.gz
/DBI-1.622.tar.gz
/DBI-1.623.tar.gz
+/DBI-1.625.tar.gz
diff --git a/perl-DBI.spec b/perl-DBI.spec
index 4170fa0..a787770 100644
--- a/perl-DBI.spec
+++ b/perl-DBI.spec
@@ -7,20 +7,24 @@
%endif
Name: perl-DBI
-Version:1.623
-Release:2%{?dist}
+Version:1.625
+Release:1%{?dist}
Summary:A database access API for perl
Group: Development/Libraries
License:GPL+ or Artistic
URL:http://dbi.perl.org/
Source0:http://www.cpan.org/authors/id/T/TI/TIMB/DBI-%{version}.tar.gz
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(strict)
# Run-time
BuildRequires: perl(base)
BuildRequires: perl(constant)
BuildRequires: perl(Carp)
# Clone is optional
BuildRequires: perl(Clone) = 0.34
+BuildRequires: perl(Config)
%if %{with coro}
BuildRequires: perl(Coro)
BuildRequires: perl(Coro::Handle)
@@ -34,16 +38,19 @@ BuildRequires: perl(DynaLoader)
BuildRequires: perl(Errno)
BuildRequires: perl(Exporter)
BuildRequires: perl(Fcntl)
+BuildRequires: perl(File::Basename)
BuildRequires: perl(File::Spec)
BuildRequires: perl(Getopt::Long)
BuildRequires: perl(IO::Dir)
BuildRequires: perl(IO::File)
BuildRequires: perl(IO::Select)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Math::BigInt)
# MLDBM is optional
%if ! ( 0%{?rhel} )
BuildRequires: perl(MLDBM)
%endif
+# Params::Util is optional
# RPC::PlClient is optional
BuildRequires: perl(RPC::PlClient) = 0.2000
# RPC::PlServer is optional
@@ -54,10 +61,17 @@ BuildRequires: perl(Scalar::Util)
BuildRequires: perl(SQL::Statement) = 1.402
%endif
BuildRequires: perl(Storable)
+BuildRequires: perl(Symbol)
BuildRequires: perl(threads)
BuildRequires: perl(Tie::Hash)
+BuildRequires: perl(UNIVERSAL)
+BuildRequires: perl(utf8)
+BuildRequires: perl(vars)
+BuildRequires: perl(warnings)
# Tests
+BuildRequires: perl(Benchmark)
BuildRequires: perl(Encode)
+BuildRequires: perl(File::Copy)
BuildRequires: perl(File::Path)
BuildRequires: perl(lib)
BuildRequires: perl(Net::Daemon::Test)
@@ -66,7 +80,7 @@ BuildRequires: perl(Test::Simple) = 0.90
# Optional tests
BuildRequires: perl(Test::Pod) = 1.00
BuildRequires: perl(Test::Pod::Coverage) = 1.04
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
Requires: perl(Math::BigInt)
# Filter unwanted dependencies
@@ -124,6 +138,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Apr 02 2013 Petr Šabata con...@redhat.com - 1.625-1
+- 1.625 bump, perl5.17 fixes
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.623-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index ad146fa..402c337 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-b45654dca3b495f3d496c359f0029d96 DBI-1.623.tar.gz
+b0521be412faff4ec8d511cd5f3f6a31 DBI-1.625.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-DBI/f19] 1.625 bump, perl5.17 fixes
Summary of changes: cf8eda6... 1.625 bump, perl5.17 fixes (*) (*) 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 947444] New: PerlIO dead-locks with threaded fork
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947444 Bug ID: 947444 Summary: PerlIO dead-locks with threaded fork Product: Fedora Version: 18 Component: perl Severity: unspecified Priority: unspecified Assignee: mmasl...@redhat.com Reporter: ppi...@redhat.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: --- Created attachment 730746 -- https://bugzilla.redhat.com/attachment.cgi?id=730746action=edit Test case As reported to upstream, there is a possible dead lock when using fork from threads and PerlIO https://rt.perl.org/rt3/Public/Bug/Display.html?id=106212. This has been fixed in commit: From 4da80956418bbe1fdc23cad0b1cbb24cd7b87609 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Patrik=20H=C3=A4gglund?= patrik.h.haggl...@ericsson.com Date: Sat, 2 Feb 2013 20:21:05 +0100 Subject: [PATCH] PATCH [perl #106212] Add PL_perlio_mutex to atfork_lock/unlock Using threads + fork() on Linux, and IO operations in the threads, the PL_perlio_mutex may be left in a locked state at the call of fork(), potentially leading to deadlock in the child process at subsequent IO operations. (Threads are pre-empted and not continued in the child process after the fork.) Therefore, ensure that the PL_perlio_mutex is unlocked in the child process, right after fork(), by using atfork_lock/unlock. (The RT text gives ways to reproduce the problem, but are not easily added to Perl's test suite) Probably all Fedoras are affected. -- 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=9NtTx6GUfVa=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 947489] Please revert the unbundling of inc::Module::Install, at least when bootstrapping
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=947489 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Petr Pisar ppi...@redhat.com --- Sure. Once koji will get healthy, I'll do that. -- 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=gczrM9m0lfa=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 918008] CVE-2013-1667 perl: DoS in rehashing code [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=918008 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2013-04-03 00:55:14 -- 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=JmD0f9abEua=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 918008] CVE-2013-1667 perl: DoS in rehashing code [fedora-all]
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=918008 --- Comment #8 from Fedora Update System upda...@fedoraproject.org --- perl-5.14.4-224.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- 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=Q0NMZKaRMea=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 908113] CPAN::Debug(3pm) is missing NAME section
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=908113 --- Comment #18 from Fedora Update System upda...@fedoraproject.org --- perl-5.14.4-224.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report. -- 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=xBGEUwNW8ia=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 908113] CPAN::Debug(3pm) is missing NAME section
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=908113 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA Last Closed||2013-04-03 00:55:25 -- 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=PGiavJIlfJa=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
[389-devel] please review: Ticket 550 - posix winsync will not create memberuid values if group entry become posix group in the same sync interval
I had to modify the original patch to work on 1.3.1, so that's why I'm sending it out for review. https://fedorahosted.org/389/ticket/550 https://fedorahosted.org/389/attachment/ticket/550/0001-Ticket-550-posix-winsync-will-not-create-memberuid-v.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
