yum update -- F16-latest = rawhide
Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. Here is some info: # [root@dhcp201-139 ~]# cat /etc/redhat-release Fedora release 16 (Verne) [root@dhcp201-139 ~]# # [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update . . . . Installing for dependencies: groff-base x86_64 1.21-5.fc17 rawhide 783 k p11-kit x86_64 0.6-1.fc17 rawhide 33 k perl-Carpnoarch 1.22-1.fc17 rawhide 16 k Transaction Summary === Install 6 Packages Upgrade 197 Packages Remove1 Package Total size: 108 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 Please report this error in http://yum.baseurl.org/report You could try running: rpm -Va --nofiles --nodigest Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2011-10-11-05-27lkgwPY.yumtx # Then I tried: # [root@dhcp201-139 ~]# rpm -Va --nofiles --nodigest [root@dhcp201-139 ~]# # Tried to clean-up the yum cache, rpm dbs: # [root@dhcp201-139 ~]# rm -rf /var/cache/yum/* [root@dhcp201-139 ~]# rm -rf /var/lib/rpm/__db* [root@dhcp201-139 ~]# rpm --rebuilddb # Then re-tried : [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update Still no dice. As it still throws -- 'ERROR with transaction check vs depsolve:' Any hints here? Meanwhile, I tried to install a clean f16 minimal guest on a latest f16 host, and it just hung. Details, I posted to fedora-virt list here - http://lists.fedoraproject.org/pipermail/virt/2011-October/002933.html -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 744904] perl-JSON-RPC should not depend on mod_perl
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=744904 Emmanuel Seyman emmanuel.sey...@club-internet.fr changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Emmanuel Seyman emmanuel.sey...@club-internet.fr 2011-10-11 07:50:57 EDT --- Okay, there's a server implementation in that package. I'll split it out in a sub-package. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: yum update -- F16-latest = rawhide
On Tue, 11 Oct 2011 17:19:22 +0530, KC (Kashyap) wrote: Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. And no /bin/sh either? It is provided by bash. ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 Then re-tried : [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update Still no dice. As it still throws -- 'ERROR with transaction check vs depsolve:' Any hints here? (Sounds more like a subject for test list.) Since this unresolved dependency is not listed in the daily rawhide report: Can you dig further and find out why you don't have anything that provides /bin/sh? How to do that? Prior to the upgrade attempt, query your local RPM database *and* also use repoquery. Then ask repoquery with the rawhide repo enabled. What do you get? Where did bash go? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Mon, 10 Oct 2011 17:18:10 -0400 Bill Nottingham wrote: Rahul Sundaram (methe...@gmail.com) said: On 10/10/2011 08:52 PM, Thomas Spura wrote: So there doesn't need to be more co-maintainers (which is welcomed anyway), but it would help to get such updates pushed to stable directly like it was without the forced period in updates-testing or a heads up before doing such an update. I think the heads up should be automated via the build system. If the required updates are due to version checks in the extensions, it might be possible to have RPM have a dependency generator that checks these and outputs the appropriate Requires/Conflicts lines, such that this could be easily caught by AutoQA. Implemented and proposed as a subpackage to mozilla-filesystem at: https://bugzilla.redhat.com/show_bug.cgi?id=745038 Any extension, which BR: mozilla-build then has the correct requires, if it's installed correctly. Correctly means here, without symlinks, like I currently do in noscript and other extensions are doing it too right now. I'd propose to finally have mozilla-noscript, which pulls all subpackages, e.g. firefox-noscript and seahorse-noscript etc, and only those subpackages require firefox OR seahorse. Comments? -Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Ethernet Installation of F15 using Apache and PXE environment on another machine
Is it possible to do an ethernet Installation of F15 using Apache and PXE environment on another machine rather than from the internet ( download.fedora.redhat.com) ? Many thanks, Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Bio-Graphics
perl-Bio-Graphics has broken dependencies in the rawhide tree: On x86_64: perl-Bio-Graphics-2.25-1.fc17.noarch requires perl(Bio::DB::BigWig) On i386: perl-Bio-Graphics-2.25-1.fc17.noarch requires perl(Bio::DB::BigWig) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: yum update -- F16-latest = rawhide
On 10/11/2011 05:29 PM, Michael Schwendt wrote: On Tue, 11 Oct 2011 17:19:22 +0530, KC (Kashyap) wrote: Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. And no /bin/sh either? It is provided by bash. That was the obvious check. I /did/ check that (forgot to mention) ## [root@dhcp201-139 ~]# ls -al /bin/sh lrwxrwxrwx. 1 root root 4 Oct 10 15:20 /bin/sh - bash ## [root@dhcp201-139 ~]# file /bin/bash /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped ## ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 Then re-tried : [root@dhcp201-139 ~]# yum --disablerepo=* --enablerepo=rawhide update Still no dice. As it still throws -- 'ERROR with transaction check vs depsolve:' Any hints here? (Sounds more like a subject for test list.) Since this unresolved dependency is not listed in the daily rawhide report: Can you dig further and find out why you don't have anything that provides /bin/sh? How to do that? Prior to the upgrade attempt, query your local RPM database *and* also use repoquery. Then ask repoquery with the rawhide repo enabled. What do you get? Where did bash go? That's what surprised me too. I did try these. 'bash' is right there. ## [root@dhcp201-139 ~]# rpm -qf `which bash` bash-4.2.10-4.fc16.x86_64 ## [root@dhcp201-139 ~]# repoquery -q --whatprovides --alldeps bash --enablerepo=rawhide --disablerepo=* bash-0:4.2.10-5.fc17.x86_64 [root@dhcp201-139 ~]# ## [root@dhcp201-139 ~]# yum repolist enabled Loaded plugins: langpacks, presto, refresh-packagekit repo idrepo name status rawhideFedora - Rawhide - Developmental packages for the next Fedora release 25,139 repolist: 25,139 [root@dhcp201-139 ~]# ## -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ethernet Installation of F15 using Apache and PXE environment on another machine
On Tue, Oct 11, 2011 at 6:09 PM, Aaron Gray aaronngray.li...@gmail.comwrote: Is it possible to do an ethernet Installation of F15 using Apache and PXE environment on another machine rather than from the internet ( download.fedora.redhat.com) ? Yes , It is possible. You can make the installation tree available via HTTP or NFS and perform a PXE based installation . Also check https://fedorahosted.org/cobbler/ -- Arun S.A.G http://zer0c00l.in/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20111011 changes
Compose started at Tue Oct 11 08:16:07 UTC 2011 Broken deps for x86_64 -- 389-admin-1.1.23-1.fc17.i686 requires libicuuc.so.46 389-admin-1.1.23-1.fc17.i686 requires libicui18n.so.46 389-admin-1.1.23-1.fc17.i686 requires libicudata.so.46 389-admin-1.1.23-1.fc17.x86_64 requires libicuuc.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicui18n.so.46()(64bit) 389-admin-1.1.23-1.fc17.x86_64 requires libicudata.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.i686 requires libicuuc.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicui18n.so.46 389-adminutil-1.1.14-1.fc16.i686 requires libicudata.so.46 389-adminutil-1.1.14-1.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-adminutil-1.1.14-1.fc16.x86_64 requires libicudata.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicuuc.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicui18n.so.46()(64bit) 389-dsgw-1.1.7-2.fc16.x86_64 requires libicudata.so.46()(64bit) acheck-0.5.1-4.fc15.noarch requires perl(Text::Aspell) assogiate-0.2.1-5.fc15.x86_64 requires libgnomevfsmm-2.6.so.1()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicuuc.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libicui18n.so.46()(64bit) bibletime-2.8.1-1.fc16.x86_64 requires libclucene.so.0()(64bit) cluster-snmp-0.18.7-1.fc16.x86_64 requires libnetsnmp.so.25()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-backup-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-client-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires rvm-tools coda-server-6.9.5-6.fc16.x86_64 requires libseglwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires libse.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librvmlwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librpc2.so.5()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires librdslwp.so.1()(64bit) coda-server-6.9.5-6.fc16.x86_64 requires liblwp.so.2()(64bit) comoonics-cdsl-py-0.2-18.noarch requires comoonics-base-py comoonics-cluster-py-0.1-24.noarch requires comoonics-base-py contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1 contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit) couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit) dh-make-0.55-3.fc15.noarch requires debhelper emacs-spice-mode-1.2.25-5.fc15.noarch requires gwave fawkes-core-0.4.2-4.fc16.i686 requires libopencv_video.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_objdetect.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_ml.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_legacy.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_imgproc.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_highgui.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_flann.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_features2d.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_core.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_contrib.so.2.2 fawkes-core-0.4.2-4.fc16.i686 requires libopencv_calib3d.so.2.2 fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_video.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_objdetect.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_ml.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_legacy.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_imgproc.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_highgui.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_flann.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_features2d.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_core.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires libopencv_contrib.so.2.2()(64bit) fawkes-core-0.4.2-4.fc16.x86_64 requires
Re: Ethernet Installation of F15 using Apache and PXE environment on another machine
On 11 October 2011 13:51, Arun SAG saga...@gmail.com wrote: On Tue, Oct 11, 2011 at 6:09 PM, Aaron Gray aaronngray.li...@gmail.comwrote: Is it possible to do an ethernet Installation of F15 using Apache and PXE environment on another machine rather than from the internet ( download.fedora.redhat.com) ? Yes , It is possible. You can make the installation tree available via HTTP or NFS and perform a PXE based installation . Also check https://fedorahosted.org/cobbler/ Thanks, still needs TFTP but this could simplify things a lot. Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ethernet Installation of F15 using Apache and PXE environment on another machine
Am 11.10.2011 15:20, schrieb Aaron Gray: Thanks, still needs TFTP but this could simplify things a lot. If you want to circumvent using TFTP and you are using gPXE (or a PXE boot ROM that supports booting from HTTP) you could point it to the pxelinux of boot.fedoraproject.org at http://alt.fedoraproject.org/pub/alt/bfo/pxelinux.0 for doing a netinstall. If your PXE boot ROM however doesn't support HTTP you're pretty much stuck with TFTP. Felix -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Ethernet Installation of F15 using Apache and PXE environment on another machine
On 11 October 2011 14:34, Felix Kaechele fe...@fetzig.org wrote: Am 11.10.2011 15:20, schrieb Aaron Gray: Thanks, still needs TFTP but this could simplify things a lot. If you want to circumvent using TFTP and you are using gPXE (or a PXE boot ROM that supports booting from HTTP) you could point it to the pxelinux of boot.fedoraproject.org at http://alt.fedoraproject.org/pub/alt/bfo/pxelinux.0 for doing a netinstall. If your PXE boot ROM however doesn't support HTTP you're pretty much stuck with TFTP. Yeah PXE TFTP only :( Thanks anyway, Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BTRFS on LVM causes long fedora-storage-init run?
On Mon, Oct 10, 2011 at 4:11 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 10.10.11 15:58, Richard Shaw (hobbes1...@gmail.com) wrote: On Mon, Oct 10, 2011 at 3:43 PM, Lennart Poettering mzerq...@0pointer.de wrote: On Mon, 10.10.11 15:13, Richard Shaw (hobbes1...@gmail.com) wrote: /var/tmp/yum-richard-R_0cAQ/x86_64/15/adobe-linux-i386 /var/tmp/yum-richard-R_0cAQ/x86_64/15/adobe-linux-i386/packages /var/tmp/yum-richard-R_0cAQ/x86_64/15/fedora /var/tmp/yum-richard-R_0cAQ/x86_64/15/fedora/packages /var/tmp/yum-richard-R_0cAQ/x86_64/15/local /var/tmp/yum-richard-R_0cAQ/x86_64/15/local/packages /var/tmp/yum-richard-R_0cAQ/x86_64/15/local-install /var/tmp/yum-richard-R_0cAQ/x86_64/15/local-install/packages Hmm, maybe some package you installed includes a weird tmpfiles rule? Can you paste grep -r . /etc/tmpfiles.d/ /usr/lib/tmpfiles.d somewhere? http://dl.dropbox.com/u/34775202/tmpfiles.txt Hmm nothing particularly suspicious here. Next step: could you copy /lib/systemd/system/systemd-tmpfiles.service to /etc/systemd/system/ and prefix the ExecStart with /usr/bin/strace -o /run/tmpfiles.strace, and then paste the output that generates in that file somewhere? I couldn't find systemd-tmpfiles.service... I assume that systemd-tmpfiles-setup.service was the correct file? I added what you suggested and I checked it twice but when I rebooted the boot process hung. Will booting to single user mode let me fix this or will I have to use some sort of rescue media? That should tell us what files tmpfiles actually accesses there. This is on rotating media I presume? Yes. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
Thomas Spura (toms...@fedoraproject.org) said:
If the required updates are due to version checks in the extensions,
it might be possible to have RPM have a dependency generator that
checks these and outputs the appropriate Requires/Conflicts lines,
such that this could be easily caught by AutoQA.
Generally speaking, could be possible (didn't look at other extensions).
I'll try to script somthing for the requires generation
like /usr/lib/rpm/pythondeps.sh. But it won't be possible to easily
generalize requires, it would be better to have Conflicts:
!-- Firefox --
em:targetApplication
Description
em:id{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/em:id
em:minVersion3.0/em:minVersion
em:maxVersion10.0a1/em:maxVersion
/Description
/em:targetApplication
There isn't only firefox in that file, there are many browsers that
aren't available in fedora, so R: Flock = 0.4 and R: Flock = 2.0.*
would be never fulfilled -- Choosing to conflict with all other
versions.
Would that be ok/sane?
You'd want:
Requires: firefox = 3.0
Conflicts: firefox 10.0a1
(You could do the first one as a conflicts, too, but since the package
is already going to have a Requires: on firefox, might as well just version
it.)
Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Upstream Release Monitor
I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Tue, Oct 11, 2011 at 09:35:33AM -0500, Nathan O. wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. The monitor compares the latest upstream version with the package in Rawhide, not in stable releases. Just bump it there and it will leave you alone :) -- # Petr Sabata pgpSkfSphbIws.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Tue, Oct 11, 2011 at 3:35 PM, Nathan O. ndowen...@gmail.com wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. Is it built in rawhide? I believe it checks the version against rawhide, not F-16. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning pida
Hello all, I am planning to orphan pida, I haven't used it since probably mid F14 cycle and I feel it needs a maintainer that will give it more attention. -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
If I remember correctly I did update it in rawhide. The master repo says it is updated to the latest version, by looking at the SPEC http://pkgs.fedoraproject.org/gitweb/?p=worker.git;a=blob_plain;f=worker.spec;hb=master On Tue, Oct 11, 2011 at 9:42 AM, Peter Robinson pbrobin...@gmail.comwrote: On Tue, Oct 11, 2011 at 3:35 PM, Nathan O. ndowen...@gmail.com wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. Is it built in rawhide? I believe it checks the version against rawhide, not F-16. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Tue, 11 Oct 2011 10:36:01 -0400
Bill Nottingham wrote:
Thomas Spura (toms...@fedoraproject.org) said:
If the required updates are due to version checks in the
extensions, it might be possible to have RPM have a dependency
generator that checks these and outputs the appropriate
Requires/Conflicts lines, such that this could be easily caught
by AutoQA.
Generally speaking, could be possible (didn't look at other
extensions). I'll try to script somthing for the requires generation
like /usr/lib/rpm/pythondeps.sh. But it won't be possible to easily
generalize requires, it would be better to have Conflicts:
!-- Firefox --
em:targetApplication
Description
em:id{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/em:id
em:minVersion3.0/em:minVersion
em:maxVersion10.0a1/em:maxVersion
/Description
/em:targetApplication
There isn't only firefox in that file, there are many browsers that
aren't available in fedora, so R: Flock = 0.4 and R: Flock = 2.0.*
would be never fulfilled -- Choosing to conflict with all other
versions.
Would that be ok/sane?
You'd want:
Requires: firefox = 3.0
Conflicts: firefox 10.0a1
(You could do the first one as a conflicts, too, but since the package
is already going to have a Requires: on firefox, might as well just
version it.)
The automatic requires proposed in bug #745038, does this:
Requires: firefox = 3.0
Requires: firefox = 10.0a1
and seems to work fine here so far. When a newer firefox-11.0 is
installed, yum should complain about it, I guess.
-Tom
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Tue, Oct 11, 2011 at 09:45:17AM -0500, Nathan O. wrote: If I remember correctly I did update it in rawhide. The master repo says it is updated to the latest version, by looking at the SPEC http://pkgs.fedoraproject.org/gitweb/?p=worker.git;a=blob_plain;f=worker.spec;hb=master There's no 2.18.1 rawhide build, though... On Tue, Oct 11, 2011 at 9:42 AM, Peter Robinson pbrobin...@gmail.comwrote: On Tue, Oct 11, 2011 at 3:35 PM, Nathan O. ndowen...@gmail.com wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. Is it built in rawhide? I believe it checks the version against rawhide, not F-16. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- # Petr Sabata pgpOGy0LBTMfF.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning pida
Hello all, I am planning to orphan pida, I haven't used it since probably mid F14 cycle and I feel it needs a maintainer that will give it more attention. If I can get 0.6.2 to build, I'll take it. -J -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On 10/11/2011 10:36 AM, Bill Nottingham wrote:
Thomas Spura (toms...@fedoraproject.org) said:
If the required updates are due to version checks in the extensions,
it might be possible to have RPM have a dependency generator that
checks these and outputs the appropriate Requires/Conflicts lines,
such that this could be easily caught by AutoQA.
Generally speaking, could be possible (didn't look at other extensions).
I'll try to script somthing for the requires generation
like /usr/lib/rpm/pythondeps.sh. But it won't be possible to easily
generalize requires, it would be better to have Conflicts:
!-- Firefox --
em:targetApplication
Description
em:id{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/em:id
em:minVersion3.0/em:minVersion
em:maxVersion10.0a1/em:maxVersion
/Description
/em:targetApplication
There isn't only firefox in that file, there are many browsers that
aren't available in fedora, so R: Flock= 0.4 and R: Flock= 2.0.*
would be never fulfilled -- Choosing to conflict with all other
versions.
Would that be ok/sane?
You'd want:
Requires: firefox= 3.0
Conflicts: firefox 10.0a1
(You could do the first one as a conflicts, too, but since the package
is already going to have a Requires: on firefox, might as well just version
it.)
What you should use is:
Add-on Compatibility Reporter 0.9.2
https://addons.mozilla.org/en-US/firefox/addon/add-on-compatibility-reporter/?src=api
--
David
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
On Tue, 11 Oct 2011 18:21:03 +0530, KC (Kashyap) wrote: On 10/11/2011 05:29 PM, Michael Schwendt wrote: On Tue, 11 Oct 2011 17:19:22 +0530, KC (Kashyap) wrote: Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. And no /bin/sh either? It is provided by bash. That was the obvious check. I /did/ check that (forgot to mention) ## [root@dhcp201-139 ~]# ls -al /bin/sh lrwxrwxrwx. 1 root root 4 Oct 10 15:20 /bin/sh - bash ## [root@dhcp201-139 ~]# file /bin/bash /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped ## That check is useless. Only files tracked by the local RPM database and repository metadata count. That's what surprised me too. I did try these. 'bash' is right there. ## [root@dhcp201-139 ~]# rpm -qf `which bash` bash-4.2.10-4.fc16.x86_64 Also a wrong test. rpm -q --whatprovides /bin/sh would have been the proper check to find the package(s) that provides /bin/sh _prior_ to your upgrade attempt. ## [root@dhcp201-139 ~]# repoquery -q --whatprovides --alldeps bash --enablerepo=rawhide --disablerepo=* bash-0:4.2.10-5.fc17.x86_64 What does that tell you? Not much. Instead: # repoquery --whatprovides /bin/sh --enablerepo=rawhide --disablerepo=* bash-0:4.2.10-5.fc17.x86_64 as you want to find out whether anything still provides /bin/sh when enabling the target repo (one could examine it further in case it isn't bash but an unexpected other package). Now as /bin/sh is still available, does the full Yum update output say anything about bash? The error you've seen is not an unresolved dependency, but something later. With an unresolved dependency, it would have bailed out even before downloading any packages. You would have had to add --skip-broken for it to continue. [...] Install 6 Packages Upgrade 197 Packages Remove1 Package Total size: 108 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 You somehow lose /bin/sh during the transaction check, which is something unexpected. Is that reproducible also after cleaning Yum's download cache? What is the full list of packages to be updated? Is the new bash on it, too? Have you looked up the downloaded package below /var/cache/yum to check it for errors? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Tue, 11 Oct 2011 09:45:17 -0500 Nathan O. wrote: If I remember correctly I did update it in rawhide. The master repo says it is updated to the latest version, by looking at the SPEC http://pkgs.fedoraproject.org/gitweb/?p=worker.git;a=blob_plain;f=worker.spec;hb=master Apparently, you didn't build it: http://koji.fedoraproject.org/koji/packageinfo?packageID=12322 -Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
Kashyap Chamarthy writes: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 I have this same problem when trying to upgrade from fedora 15 to rawhide. I noticed that groff-base package have 2 /bin/sh as dependency, is there some whitespace or some other error? http://koji.fedoraproject.org/koji/rpminfo?rpmID=2708265 Requires /bin/sed /bin/sh /bin/sh config(groff-base) = 1.21-5.fc17 libc.so.6 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
On Tuesday 11 October 2011 18:22:34, Tomi Leppikangas wrote: Kashyap Chamarthy writes: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 I have this same problem when trying to upgrade from fedora 15 to rawhide. I noticed that groff-base package have 2 /bin/sh as dependency, is there some whitespace or some other error? I probably missed that. And I will take a look at it. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
On Tue, 11 Oct 2011 19:22:34 +0300, TL (Tomi) wrote: Kashyap Chamarthy writes: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 I have this same problem when trying to upgrade from fedora 15 to rawhide. I noticed that groff-base package have 2 /bin/sh as dependency, is there some whitespace or some other error? http://koji.fedoraproject.org/koji/rpminfo?rpmID=2708265 Requires /bin/sed /bin/sh /bin/sh config(groff-base) = 1.21-5.fc17 libc.so.6 Looks normal if you check the Requires generating at the bottom of the build log: http://kojipkgs.fedoraproject.org/packages/groff/1.21/5.fc17/data/logs/x86_64/build.log If it had a weird character in a dependency, the depsolving would fail already. -- Fedora release 16 (Verne) - Linux 3.1.0-0.rc9.git0.0.fc16.x86_64 loadavg: 0.19 0.37 0.20 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Reviving packages
In trying to clean up the broken dependencies report, I intend to revive three retired packages: lwp: https://bugzilla.redhat.com/show_bug.cgi?id=745216 rpc2: https://bugzilla.redhat.com/show_bug.cgi?id=745218 rvm: https://bugzilla.redhat.com/show_bug.cgi?id=745219 In accordance with Fedora policy (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), I am posting here, and asking for help in re-reviewing these packages. They are all simple and should be quick reviews, I would appreciate any help in finishing off these reviews (will trade reviews or favors). ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
On Tue, Oct 11, 2011 at 01:24:02PM -0400, Tom Callaway wrote: In trying to clean up the broken dependencies report, I intend to revive three retired packages: lwp: https://bugzilla.redhat.com/show_bug.cgi?id=745216 rpc2: https://bugzilla.redhat.com/show_bug.cgi?id=745218 rvm: https://bugzilla.redhat.com/show_bug.cgi?id=745219 In accordance with Fedora policy (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), I am posting here, and asking for help in re-reviewing these packages. They are all simple and should be quick reviews, I would appreciate any help in finishing off these reviews (will trade reviews or favors). ~tom These are all needed for coda. Last I looked at them, getting them building properly was not so hard, getting them to run properly was a significant effort, one that may not be worth it, unless there are way more coda users out there than I'm aware of. Keeping rpc2 and rvm might be of value, but at the very least we should probably focus effort on moving coda away from lwp and onto threads if at all possible. Neil == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
On Tue, 2011-10-11 at 13:24 -0400, Tom Callaway wrote: In trying to clean up the broken dependencies report, I intend to revive three retired packages: lwp: https://bugzilla.redhat.com/show_bug.cgi?id=745216 I had a few spare minutes today, so I reviewed and approved this one. signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
TFTP not working on F15 as well as updated F14
I have two F15 machines one a desktop which is running the new Gnome 3 desktop and a laptop not running the new desktop. TFTP is not working on the desktop machine on F15 as it was not working on the updated F14. It worked on F14 before the update. I installed two servers using PXE using it. TFTP is however running on the F15 laptop. AFAICT I have eliminated all reasons for it not running on the Fedora User list with users there. There are two recent posts there one on F15 one on the updated F14. Can someone please look into this please. Many thanks in advance, Aaron -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
On 10/11/2011 01:42 PM, Neil Horman wrote: These are all needed for coda. Last I looked at them, getting them building properly was not so hard, getting them to run properly was a significant effort, one that may not be worth it, unless there are way more coda users out there than I'm aware of. Keeping rpc2 and rvm might be of value, but at the very least we should probably focus effort on moving coda away from lwp and onto threads if at all possible. I don't disagree with this at all, but in the interim, things seem to work and I'm willing to look at bugs in this stack. ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TFTP not working on F15 as well as updated F14
On 10/11/2011 01:46 PM, Aaron Gray wrote: I have two F15 machines one a desktop which is running the new Gnome 3 desktop and a laptop not running the new desktop. TFTP is not working on the desktop machine on F15 as it was not working on the updated F14. It worked on F14 before the update. I installed two servers using PXE using it. I assume you mean TFTP server, here. Can you attach copies of the relevant config files and any errors that show up in the logs (server or client side)? ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Sun, 2011-10-09 at 13:16 +0200, Thomas Spura wrote: On Sun, 9 Oct 2011 11:05:28 +0200 Till Maas wrote: On Sat, Oct 08, 2011 at 11:43:58PM +0200, Christoph Wickert wrote: 3. Can someone (I'm looking at you, QA) make sure all extensions are still compatible? The problem is that testers seem to ignore test cases provided for updates, because there is an test case to check for extension compatibility. That doesn't help much. It would be great, when bodhi would allow me to add an updated mozilla-noscript to the firefox update, when I notice, that the new firefox upadate in testing breaks it. Otherwise, firefox is pushed to stable more faster, than mozilla-noscript and it's broken for some time, till it was long enought in updates-testing. It is possible to add packages to updates; the issue is permissions. I'm not entirely sure how it works at present, but it's _something_ like 'only people who are explicitly maintainers of one of the packages in the initial update set can edit the update'. Notably, there is no provenpackager exemption for editing updates: provenpackagers can't edit any update as you might expect. There obviously is a _legitimate_ question as to whether you ought to be able to add your package into anyone else's update if you aren't a provenpackager; it's not necessarily something we'd want to do. But I think provenpackagers probably should be allowed to edit any update. It's NOT possible to push it faster out there, because I usually don't get much karma. For the last update, I got 2 new bug reports, that noscript is broken, but not a single +1 karma for the same issue, although linking in both bug reports and being in updates-testing anyways... It does seem to be the case that negative karma is easier to come by than positive, yeah. I'm not sure there's much we can do about this besides 'game' the rules to account for it, as we're doing already to some extent. -- 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: Firefox on Fedora: No longer funny
On Sun, 2011-10-09 at 11:14 -0600, Stephen John Smoogen wrote: On Sun, Oct 9, 2011 at 05:28, Christoph Wickert christoph.wick...@googlemail.com wrote: Am Sonntag, den 09.10.2011, 12:58 +0200 schrieb drago01: On Sun, Oct 9, 2011 at 12:50 PM, Christoph Wickert christoph.wick...@googlemail.com wrote: Am Sonntag, den 09.10.2011, 11:34 +0200 schrieb drago01: On Sat, Oct 8, 2011 at 11:43 PM, Christoph Wickert christoph.wick...@googlemail.com wrote: That just reminds me while packing firefox extensions is not a good idea. How else would you install an extension globally for all users? How many multi-user systems run firefox from them? At the university where I used to work we had this and it was awful because the tool itself isn't written for this use case. This was a problem in 2008.. it hasn't gotten any better since then. Very few applications are written with the old world view of centralizing usage. It doesn't fit either the largest use case (one user-one device) or the newer centralized usage where items are in a cloud and gotten through a portal system. I think our old way of doing things is becoming a corner case to be routed around. Yeah. FWIW I just don't use the Fedora packaged extensions; I use adblock plus, but I install it via Firefox's add-on system, not from the package. I'm pretty sympathetic to Smooge's view here, Firefox just isn't really designed for add-ons to be installed via distro packages, it seems. -- 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: Firefox on Fedora: No longer funny
On Mon, 2011-10-10 at 11:40 -0600, Tim Flink wrote: On Sun, 9 Oct 2011 13:16:52 +0200 Thomas Spura toms...@fedoraproject.org wrote: It would be great, when bodhi would allow me to add an updated mozilla-noscript to the firefox update, when I notice, that the new firefox upadate in testing breaks it. Otherwise, firefox is pushed to stable more faster, than mozilla-noscript and it's broken for some time, till it was long enought in updates-testing. It's NOT possible to push it faster out there, because I usually don't get much karma. For the last update, I got 2 new bug reports, that noscript is broken, but not a single +1 karma for the same issue, although linking in both bug reports and being in updates-testing anyways... (Hope to not get the usual That's the job of AutoQA answer...) On the bright side, I don't see how AutoQA could help in this situation so my answer isn't that's the job of AutoQA. On the down side, I don't really have any good answers on how to improve the situation. Well, I do. It seems pretty simple: we only have a few extensions packaged. We should consider extensions to be effectively API dependencies of Firefox, which means any Firefox update must also include updates for the dependencies - extensions. We should ask the Firefox maintainers and extension maintainers to co-ordinate so that each Firefox update which changes the extension API number (or whatever it is that causes extensions to be marked 'incompatible') includes rebuilds of each extension. That way Firefox can't be pushed without the extensions. Nothing in the above paragraph looks particularly onerous or difficult to organize, to me. We're only talking about a few packages and packagers. -- 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: yum update -- F16-latest = rawhide
On 10/11/2011 08:16 PM, Jan Vcelak wrote: On Tuesday 11 October 2011 18:22:34, Tomi Leppikangas wrote: Kashyap Chamarthy writes: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 I have this same problem when trying to upgrade from fedora 15 to rawhide. I noticed that groff-base package have 2 /bin/sh as dependency, is there some whitespace or some other error? I probably missed that. And I will take a look at it. This is a bug in rpm's handling of %pretrans dependencies. I'll try to get it fixed tomorrow, BUT this also does point out a problem in the package: %pretrans scripts can almost never in real life be /bin/sh scripts, because on initial installation, at the point where %pretrans scripts get executed there is no shell! Or anything else for that matter. The only kind of %pretrans script that always work are ones using the embedded Lua interpreter, ie '%pretrans -p lua'. External interpreters in %pretrans are /supposed/ to work in upgrade scenarios (barring this bug, duh), but as in practise you can never guarantee a package is only ever applied as an update on an already running system, %pretrans scriptlets using /bin/sh or such external interpreter are not usable. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
On 10/11/2011 11:32 PM, Panu Matilainen wrote: On 10/11/2011 08:16 PM, Jan Vcelak wrote: On Tuesday 11 October 2011 18:22:34, Tomi Leppikangas wrote: Kashyap Chamarthy writes: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 I have this same problem when trying to upgrade from fedora 15 to rawhide. I noticed that groff-base package have 2 /bin/sh as dependency, is there some whitespace or some other error? I probably missed that. And I will take a look at it. This is a bug in rpm's handling of %pretrans dependencies. I'll try to get it fixed tomorrow, BUT this also does point out a problem in the package: %pretrans scripts can almost never in real life be /bin/sh scripts, because on initial installation, at the point where %pretrans scripts get executed there is no shell! Or anything else for that matter. The only kind of %pretrans script that always work are ones using the embedded Lua interpreter, ie '%pretrans -p lua'. External interpreters in %pretrans are /supposed/ to work in upgrade scenarios (barring this bug, duh), but as in practise you can never guarantee a package is only ever applied as an update on an already running system, %pretrans scriptlets using /bin/sh or such external interpreter are not usable. Thanks Panu for taking a look. - Panu - -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning pida
Hello all, I am planning to orphan pida, I haven't used it since probably mid F14 cycle and I feel it needs a maintainer that will give it more attention. If I can get 0.6.2 to build, I'll take it. I did. Anyone interested in having pida 0.6.2 would be welcome to review the following, which it needs: https://bugzilla.redhat.com/show_bug.cgi?id=745233 https://bugzilla.redhat.com/show_bug.cgi?id=695022 Thanks! -J -J -AdamM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
rvm: https://bugzilla.redhat.com/show_bug.cgi?id=745219 I'm reviewing this. In accordance with Fedora policy (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), I am posting here, and asking for help in re-reviewing these packages. They are all simple and should be quick reviews, I would appreciate any help in finishing off these reviews (will trade reviews or favors). ~tom == Fedora Project -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
On 10/11/2011 08:38 PM, Michael Schwendt wrote: On Tue, 11 Oct 2011 18:21:03 +0530, KC (Kashyap) wrote: On 10/11/2011 05:29 PM, Michael Schwendt wrote: On Tue, 11 Oct 2011 17:19:22 +0530, KC (Kashyap) wrote: Heya, I'm trying to get rawhide running by yum updating a minimal footprint F16 virtual machine. Only @core package, so no gnome-* nothing else. And no /bin/sh either? It is provided by bash. That was the obvious check. I /did/ check that (forgot to mention) ## [root@dhcp201-139 ~]# ls -al /bin/sh lrwxrwxrwx. 1 root root 4 Oct 10 15:20 /bin/sh - bash ## [root@dhcp201-139 ~]# file /bin/bash /bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped ## That check is useless. Only files tracked by the local RPM database and repository metadata count. That's what surprised me too. I did try these. 'bash' is right there. ## [root@dhcp201-139 ~]# rpm -qf `which bash` bash-4.2.10-4.fc16.x86_64 Also a wrong test. rpm -q --whatprovides /bin/sh would have been the proper check to find the package(s) that provides /bin/sh _prior_ to your upgrade attempt. ### [root@dhcp201-139 ~]# rpm -q --whatprovides /bin/sh bash-4.2.10-4.fc16.x86_64 [root@dhcp201-139 ~]# ### ## [root@dhcp201-139 ~]# repoquery -q --whatprovides --alldeps bash --enablerepo=rawhide --disablerepo=* bash-0:4.2.10-5.fc17.x86_64 What does that tell you? Not much. Instead: # repoquery --whatprovides /bin/sh --enablerepo=rawhide --disablerepo=* bash-0:4.2.10-5.fc17.x86_64 Right, I notice the same too. as you want to find out whether anything still provides /bin/sh when enabling the target repo (one could examine it further in case it isn't bash but an unexpected other package). Now as /bin/sh is still available, does the full Yum update output say anything about bash? If you mean, just yum update on F16 (w/o enabling rawhide) -- no. If you mean, when target repo(rawhide) is enabled, it /does/ attempt to update 'bash' package. -- . . bashx86_644.2.10-5.fc17 rawhide 978 k -- The error you've seen is not an unresolved dependency, but something later. With an unresolved dependency, it would have bailed out even before downloading any packages. You would have had to add --skip-broken for it to continue. [...] Install 6 Packages Upgrade 197 Packages Remove1 Package Total size: 108 M Is this ok [y/N]: y Downloading Packages: Running Transaction Check ERROR with transaction check vs depsolve: /bin/sh is needed by groff-base-1.21-5.fc17.x86_64 You somehow lose /bin/sh during the transaction check, which is something unexpected. Is that reproducible also after cleaning Yum's download cache? Yeah, I was able to reproduce it. I /did/ clear the yum's cache(in fact, removed the var/cache/yum/* ). What is the full list of packages to be updated? I've uploaded it here: http://kashyapc.fedorapeople.org/full-list-of-rawhide-pkgs-to-be-updated.txt Is the new bash on it, too? Yes. This is the version it tries to update to - bash-4.2.10-5.fc17.x86_64.rpm Have you looked up the downloaded package below /var/cache/yum to check it for errors? Would the below suffice ? ### [root@dhcp201-139 packages]# pwd /var/cache/yum/x86_64/16/rawhide/packages [root@dhcp201-139 packages]# rpm -Vp bash-4.2.10-5.fc17.x86_64.rpm [root@dhcp201-139 packages]# ### Thanks for you help so far. -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Tue, 11 Oct 2011 12:01:00 -0400 David Michael wrote: Hi, On Tue, Oct 11, 2011 at 10:45 AM, Thomas Spura toms...@fedoraproject.org wrote: The automatic requires proposed in bug #745038, does this: Requires: firefox = 3.0 Requires: firefox = 10.0a1 and seems to work fine here so far. When a newer firefox-11.0 is installed, yum should complain about it, I guess. About two months ago I started looking into Mozilla extension packaging guidelines. The draft I found as a base[1] suggests not using dependencies on applications, and I agree with the idea among, among others listed. (I.e. if a user wants HTTPS-Everywhere for Seamonkey, they should not be forced to install Firefox.) +1 Would you mind reading over the draft and considering the points where it conflicts with your script? If you think there is value in pursuing similar Mozilla extension guidelines, I can also try to get my additions uploaded to the wiki. If not, perhaps some of the files I have been using locally (such as a spec template or a script to create directories for all supported applications in the install.rdf) could still be of use in the mozilla-build package. I'm using it partly. The draft suggests to install anything into /usr/share/mozilla/extensions/common and then symlink to all browsers supported in Fedora, e.g. into /usr/share/mozilla/extensions/$browser_id/$extension_id (But I do it manually, this seems to be a new draft, but I like the xpi_unpack cmds etc, that could be easy integrated into the mozilla-build package.) The main *BIG* difference is, that draft symlinks the extension *directory* and the script expects a install.rdf file below that. This means, the symlinking needs to happen one step below that, so that all files inside of the extension_id folder are symlinked, but the install.rdf still needs to be a real copy, so it can be opened at build time. Rationale: A directory symlink can't be resolved at build time, so we cannot follow that symlink on build time. When that's changed, the scripts are working fine along each other. About no dependency using from above: The dependencies will be added automatic with the scripts, so to avoid pulling in e.g. seamonkey, when you only want to have the firefox extension, there need to be one package for each extension, which owns /usr/share/mozilla/extensions/$browser_id/$extension_id. This way e.g. firefox-$extension would automaticalls require the correct firefox versions but no seahorse, because that has to be owned by seahorse-$extension - just as an example, but it would make sense. Kalev, does this make sense? Can this be integrated into the drafts? I'll try to add those macros proposed there into /usr/lib/rpm/macros.mozilla and see if they really work out. -Tom P.S. A working example is uploaded to fedorapeople at [1], which has this outputs in the end with rpmbuild: :) Processing files: firefox-noscript-2.1.4-1.fc15.noarch Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(FileDigests) = 4.6.0-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Requires: firefox = 10.0a1 firefox = 3.0 Processing files: seamonkey-noscript-2.1.4-1.fc15.noarch Requires(rpmlib): rpmlib(CompressedFileNames) = 3.0.4-1 rpmlib(FileDigests) = 4.6.0-1 rpmlib(PayloadFilesHavePrefix) = 4.0-1 Requires: seamonkey = 2.0 seamonkey = 2.7a1 [1] http://tomspur.fedorapeople.org/moz_draft/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Stray Python 3 bytecode files in rawhide(f17) (bug 722578)
Python 3.2's distutils was byte-compiling .py files to the wrong location, putting the .pyc/.pyo files in the same directory as the .py files, rather than in the __pycache__ subdirectory. This has led to some python3 packages having duplicate .pyc files in their payloads: https://bugzilla.redhat.com/show_bug.cgi?id=722578 This is now fixed as of today's rawhide (in python3-3.2.2-8.fc17). I mentioning it here because there's a chance that it might lead to some package builds breaking, due to missing .pyc files. This could happen if %files manifest had worked around the duplication by explicitly listing those duplicate files, which won't exist anymore. If you see this, you ought to be able to fix it by removing the no-longer-needed workaround from the %files manifest in the specfile. Hope this makes sense; sorry for any inconvenience Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Tue, Oct 11, 2011 at 10:49:54AM -0700, Adam Williamson wrote: There obviously is a _legitimate_ question as to whether you ought to be able to add your package into anyone else's update if you aren't a provenpackager; it's not necessarily something we'd want to do. But I think provenpackagers probably should be allowed to edit any update. There is an easy to answer question whether package maintainers should be able to specify that a certain build needs to be pushed to stable when some other build is pushed to stable. It is a different question whether the current model of grouping builds together as an update is a good idea. Regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Tue, 11 Oct 2011 10:57:35 -0700 Adam Williamson wrote: On Mon, 2011-10-10 at 11:40 -0600, Tim Flink wrote: On Sun, 9 Oct 2011 13:16:52 +0200 Thomas Spura toms...@fedoraproject.org wrote: It would be great, when bodhi would allow me to add an updated mozilla-noscript to the firefox update, when I notice, that the new firefox upadate in testing breaks it. Otherwise, firefox is pushed to stable more faster, than mozilla-noscript and it's broken for some time, till it was long enought in updates-testing. It's NOT possible to push it faster out there, because I usually don't get much karma. For the last update, I got 2 new bug reports, that noscript is broken, but not a single +1 karma for the same issue, although linking in both bug reports and being in updates-testing anyways... (Hope to not get the usual That's the job of AutoQA answer...) On the bright side, I don't see how AutoQA could help in this situation so my answer isn't that's the job of AutoQA. On the down side, I don't really have any good answers on how to improve the situation. Well, I do. It seems pretty simple: we only have a few extensions packaged. We should consider extensions to be effectively API dependencies of Firefox, which means any Firefox update must also include updates for the dependencies - extensions. We should ask the Firefox maintainers and extension maintainers to co-ordinate so that each Firefox update which changes the extension API number (or whatever it is that causes extensions to be marked 'incompatible') includes rebuilds of each extension. That way Firefox can't be pushed without the extensions. Nothing in the above paragraph looks particularly onerous or difficult to organize, to me. We're only talking about a few packages and packagers. Firefox can be pushed without the extensions, because the broken deps mail can be ignored. This won't be the case, once AutoQA is able to stop updates, which is not a solution to the current problem, so I didn't want to talk about that much. Nevertheless, it could be a good first step to get notified of problems, when firefox maintainer delay the updates and only build rawhide, so that broken deps have a chance to notify people. That's why I'm working towards this direction. -Tom -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Reviving packages
On 10/11/2011 11:59 PM, Kashyap Chamarthy wrote: rvm: https://bugzilla.redhat.com/show_bug.cgi?id=745219 I'm reviewing this. Done. In accordance with Fedora policy (https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_a_Deprecated_Package), I am posting here, and asking for help in re-reviewing these packages. They are all simple and should be quick reviews, I would appreciate any help in finishing off these reviews (will trade reviews or favors). ~tom == Fedora Project -- /kashyap -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On Tue, 2011-10-11 at 20:46 +0200, Thomas Spura wrote: Well, I do. It seems pretty simple: we only have a few extensions packaged. We should consider extensions to be effectively API dependencies of Firefox, which means any Firefox update must also include updates for the dependencies - extensions. We should ask the Firefox maintainers and extension maintainers to co-ordinate so that each Firefox update which changes the extension API number (or whatever it is that causes extensions to be marked 'incompatible') includes rebuilds of each extension. That way Firefox can't be pushed without the extensions. Nothing in the above paragraph looks particularly onerous or difficult to organize, to me. We're only talking about a few packages and packagers. Firefox can be pushed without the extensions, because the broken deps mail can be ignored. This won't be the case, once AutoQA is able to stop updates, which is not a solution to the current problem, so I didn't want to talk about that much. I'm not talking about _technical_ enforcement here but policy enforcement: yes, it would still be technically possible for the Firefox maintainer to push an update, there would be no code safeguards in place to prevent it happening. I'm simply saying that if you all get together and ensure that you agree it should happen and work out some procedures to make sure it doesn't, then the problem would still be solved. We don't need technological enforcement for everything, sometimes just getting people to sit down with each other and work out a process that solves the problem can work just fine. -- 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: systemd and mounting filesystems
On Tue, 11.10.11 03:38, Lennart Poettering (mzerq...@0pointer.de) wrote: [Unit] After=network.target Before=remote-fs-pre.target Wants=remote-fs-pre.target This should appear in F16 soon. This is now waiting in bodhi. Would be cool if you could check if this works as intended for you! Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum update -- F16-latest = rawhide
On Tuesday 11 October 2011 20:02:41, Panu Matilainen wrote: This is a bug in rpm's handling of %pretrans dependencies. I'll try to get it fixed tomorrow, BUT this also does point out a problem in the package: %pretrans scripts can almost never in real life be /bin/sh scripts, because on initial installation, at the point where %pretrans scripts get executed there is no shell! Or anything else for that matter. The only kind of %pretrans script that always work are ones using the embedded Lua interpreter, ie '%pretrans -p lua'. External interpreters in %pretrans are /supposed/ to work in upgrade scenarios (barring this bug, duh), but as in practise you can never guarantee a package is only ever applied as an update on an already running system, %pretrans scriptlets using /bin/sh or such external interpreter are not usable. Thank you for explaining this. This didn't come to my mind. I will rewrite the script to Lua. RPM is very uncomfortable when you need to replace a directory with a symbolic link. I do not know, how often this is needed, but some simplification would be appreciated. ;-) Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
Hi, On Tue, Oct 11, 2011 at 09:35:33AM -0500, Nathan O. wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. usually only one bug report per version is created. I did not find the reason why several bugs were reported for worker. Nevertheless I noticed that an old version of the reporting tool was running that did not abort bug reporting when the upstream version was found in the sources file in Fedora's SCM. This is now fixed. If you note that more than one bug per upstream version is reported again, please tell me. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
Thanks for all the help, and glad it seemed to help you find a issue with URM, Till On Tue, Oct 11, 2011 at 3:03 PM, Till Maas opensou...@till.name wrote: Hi, On Tue, Oct 11, 2011 at 09:35:33AM -0500, Nathan O. wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. usually only one bug report per version is created. I did not find the reason why several bugs were reported for worker. Nevertheless I noticed that an old version of the reporting tool was running that did not abort bug reporting when the upstream version was found in the sources file in Fedora's SCM. This is now fixed. If you note that more than one bug per upstream version is reported again, please tell me. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Proventesters meetup 2011-10-12 at 18UTC
We are going to be having another proventesters meetup tomorrow on IRC in #fedora-meeting at 18:00UTC. Purpose of meetup: Brainstorm ideas on improving testing and processes for testing updates. * Intro/gather more agenda items * Recruiting more proventesters/testers. * One stop page for updates testing resources * Your amazing agenda item here. Please do join us if you are a proventester, want to become one, or have ideas for improving the testing of updates. Note that this is not the venue for changing the updates policy, see FESCo for that, this is an attempt to get things working better within our existing updates policy. Hope to see folks there! kevin signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
Le dimanche 09 octobre 2011 à 13:28 +0200, Christoph Wickert a écrit : Am Sonntag, den 09.10.2011, 12:58 +0200 schrieb drago01: That just reminds me while packing firefox extensions is not a good idea. How else would you install an extension globally for all users? Or automate the installation of the addon ( like cobbler/pxe installation ) -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TFTP not working on F15 as well as updated F14
On 11 October 2011 18:49, Tom Callaway tcall...@redhat.com wrote: On 10/11/2011 01:46 PM, Aaron Gray wrote: I have two F15 machines one a desktop which is running the new Gnome 3 desktop and a laptop not running the new desktop. TFTP is not working on the desktop machine on F15 as it was not working on the updated F14. It worked on F14 before the update. I installed two servers using PXE using it. I assume you mean TFTP server, here. Can you attach copies of the relevant config files and any errors that show up in the logs (server or client side)? Tom, AFAICT by using a remote machine both the server and client are not functioning. I will go through everything again tomorrow and do a proper report as it is late now. Many thanks for getting back to me and offering to look into this, Aaron ~tom == Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Package review SIG dead?
Am Samstag, 8. Oktober 2011, 18:55:11 schrieb tim.laurid...@gmail.com: On Fri, Oct 7, 2011 at 8:39 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2011-10-07 at 17:49 +0530, Rahul Sundaram wrote: On 10/07/2011 02:49 PM, Stanislav Ochotnicky wrote: I know a lot of people wanted to have a discussion about this first, but since we had the opportunity to hack on this we did. I believe there are still many of us still interested, just not knowing what exactly we should do next. [1] https://github.com/timlau/FedoraReview [2] https://github.com/sochotnicky/FedoraReview/tree/lang-checks This should be in the Fedora repository I hear they're having trouble getting the package reviewed ducks -- It is not the review there is the problem, it is these damn QA folks :) Tim cool stuff! anybody working on a package? Greg -- And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports on it, you know they are just evil lies. (By Linus Torvalds, linus.torva...@cs.helsinki.fi) 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: Upstream Release Monitor
On Tue, Oct 11, 2011 at 03:07:11PM -0500, Nathan O. wrote: Thanks for all the help, and glad it seemed to help you find a issue with URM, Till Thank you for the report. I dug a little deeper and identified and fixed the bug that was responsible for the multiple bug reports. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
Thanks, and your welcome On Tue, Oct 11, 2011 at 3:36 PM, Till Maas opensou...@till.name wrote: On Tue, Oct 11, 2011 at 03:07:11PM -0500, Nathan O. wrote: Thanks for all the help, and glad it seemed to help you find a issue with URM, Till Thank you for the report. I dug a little deeper and identified and fixed the bug that was responsible for the multiple bug reports. Kind regards Till -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Firefox on Fedora: No longer funny
On 10/11/2011 09:32 PM, Thomas Spura wrote: The main *BIG* difference is, that draft symlinks the extension *directory* and the script expects a install.rdf file below that. This means, the symlinking needs to happen one step below that, so that all files inside of the extension_id folder are symlinked, but the install.rdf still needs to be a real copy, so it can be opened at build time. Rationale: A directory symlink can't be resolved at build time, so we cannot follow that symlink on build time. When that's changed, the scripts are working fine along each other. Could just use relative symlinks for the directories, so that they can be resolved at build time. About no dependency using from above: The dependencies will be added automatic with the scripts, so to avoid pulling in e.g. seamonkey, when you only want to have the firefox extension, there need to be one package for each extension, which owns /usr/share/mozilla/extensions/$browser_id/$extension_id. This way e.g. firefox-$extension would automaticalls require the correct firefox versions but no seahorse, because that has to be owned by seahorse-$extension - just as an example, but it would make sense. Yeah, I think there are two alternatives: a) one big package and no requires on specific browsers, b) split packages and each package requires a specific browser My draft used (a), but either way would work. Kalev, does this make sense? Can this be integrated into the drafts? I'll try to add those macros proposed there into /usr/lib/rpm/macros.mozilla and see if they really work out. Could you just fork my draft and amend it? I am not sure I am sufficiently interested in properly finishing it up. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] Note for people with EFI installs: install grub-efi!
Hey, folks. There's a grub update in updates-testing atm (being pushed stable soon) which splits the EFI stuff off into a new grub-efi subpackage. If you have an EFI install of F16 you will need to have grub-efi installed or else your system won't boot any more. So, if you have an EFI install, install the grub-efi package! -- 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: Fedora 16 Final Release Criterion for Xen DomU
On 2011-10-10 12:05, David Nalley wrote: On Mon, Oct 10, 2011 at 2:36 PM, Adam Miller maxamill...@fedoraproject.org wrote: Do any of those cloud providers ever run the stock image or do they roll their own with a custom built kernel anyways? I don't have a lot of insight into this but was just curious what the landscape is looking like out there. I personally think it would be cool to have F16 boot/install as DomU out of the box, but I don't really have a dog in the fight either way... just an idle curiousity. Well at least for Amazon, what is there is what we (Fedora) push up, so it's all Fedora now, with our own kernel. I am sure Max Spevack and Justin Forbes can speak to this more intelligently than I can. You are correct: Fedora's images in Amazon EC2 are composed entirely of software in Fedora's repositories, including the kernel. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
yubikey
Curious to know, I am thinking about getting a Yubikey to use on FAS and other related logins. I seen you must burn the key. I am concidering getting the Yubikey with the Lasspass subscription included. The question is, if I burn the key first then is it still usuable on Lastpass? I am assuming that it will still be ok. Also what is your opinion on the Yubikey? I read a little on a LWN article that on a Fedora devel mailing list there was a debate on the security issue of the YK. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On 10/11/2011 08:38 PM, Nathan O. wrote: Curious to know, I am thinking about getting a Yubikey to use on FAS and other related logins. I seen you must burn the key. I am concidering getting the Yubikey with the Lasspass subscription included. The question is, if I burn the key first then is it still usuable on Lastpass? I am assuming that it will still be ok. Also what is your opinion on the Yubikey? I read a little on a LWN article that on a Fedora devel mailing list there was a debate on the security issue of the YK. As far as I know if you burn the key you will lose the ability to use the yubikey's servers and I'm guessing coincidentally the lastpass as well. I have seen that you are allowed to upload a new key to their servers to restore its useability. So that may be one avenue to look into. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yubikey
On Tue, 11 Oct 2011, Nathanael D. Noblet wrote: As far as I know if you burn the key you will lose the ability to use the yubikey's servers and I'm guessing coincidentally the lastpass as well. I have seen that you are allowed to upload a new key to their servers to restore its useability. So that may be one avenue to look into. If these keys are still the AES symmetric keys, do not upload them to any third party - those type of keys cannot and should not be used with different entities. I thought the newer yubi keys had more then one slot though, so perhaps one slot can be used for FAS, and the other for the yubisoft servers. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: TFTP not working on F15 as well as updated F14
On Tue, 2011-10-11 at 21:22 +0100, Aaron Gray wrote: On 11 October 2011 18:49, Tom Callaway tcall...@redhat.com wrote: On 10/11/2011 01:46 PM, Aaron Gray wrote: I have two F15 machines one a desktop which is running the new Gnome 3 desktop and a laptop not running the new desktop. TFTP is not working on the desktop machine on F15 as it was not working on the updated F14. It worked on F14 before the update. I installed two servers using PXE using it. I assume you mean TFTP server, here. Can you attach copies of the relevant config files and any errors that show up in the logs (server or client side)? Tom, AFAICT by using a remote machine both the server and client are not functioning. I will go through everything again tomorrow and do a proper report as it is late now. Many thanks for getting back to me and offering to look into this, Aaron Is your issue similar to: https://bugzilla.redhat.com/show_bug.cgi?id=739534 ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream Release Monitor
On Tue, Oct 11, 2011 at 10:03:55PM +0200, Till Maas wrote: Hi, On Tue, Oct 11, 2011 at 09:35:33AM -0500, Nathan O. wrote: I am curious or maybe giving an idea, but I have my package listed there and currently there is an update for the package I have added to the list. Well I have the package in bodhi, which I believe is in testing right now. The problem is that the URM(Upstream release monitoring) keeps opening a new bug saying there is a new version available, so I have to keep closing them as duplicates. I think that it should only report it once for each new version or until maybe the previous bug report says ON_QA. usually only one bug report per version is created. I did not find the reason why several bugs were reported for worker. Nevertheless I noticed that an old version of the reporting tool was running that did not abort bug reporting when the upstream version was found in the sources file in Fedora's SCM. This is now fixed. If you note that more than one bug per upstream version is reported again, please tell me. out of interest - are there any plans to auto-close bugs once the new version hits rawhide? Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 718870] Missing dependency in perl-SVK package
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=718870 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-SVK-2.2.3-6.fc16 |perl-SVK-2.2.3-6.fc15 --- Comment #6 from Fedora Update System upda...@fedoraproject.org 2011-10-11 04:30:00 EDT --- perl-SVK-2.2.3-6.fc15 has been pushed to the Fedora 15 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 718870] Missing dependency in perl-SVK package
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=718870 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Fixed In Version|perl-SVK-2.2.3-6.fc15 |perl-SVK-2.2.3-6.fc14 --- Comment #7 from Fedora Update System upda...@fedoraproject.org 2011-10-11 04:30:44 EDT --- perl-SVK-2.2.3-6.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 745070] New: perl-DateTime-TimeZone-1.40 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-DateTime-TimeZone-1.40 is available https://bugzilla.redhat.com/show_bug.cgi?id=745070 Summary: perl-DateTime-TimeZone-1.40 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-DateTime-TimeZone AssignedTo: iarn...@gmail.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: iarn...@gmail.com, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.40 Current version in Fedora Rawhide: 1.39 URL: http://search.cpan.org/dist/DateTime-TimeZone/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 745071] New: perl-POE-Component-IRC-6.74 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-POE-Component-IRC-6.74 is available https://bugzilla.redhat.com/show_bug.cgi?id=745071 Summary: perl-POE-Component-IRC-6.74 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-POE-Component-IRC AssignedTo: cw...@alumni.drew.edu ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: cw...@alumni.drew.edu, fedora-perl-devel-l...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 6.74 Current version in Fedora Rawhide: 6.71 URL: http://search.cpan.org/dist/POE-Component-IRC/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 745072] New: perl-XML-LibXSLT-1.73 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: perl-XML-LibXSLT-1.73 is available https://bugzilla.redhat.com/show_bug.cgi?id=745072 Summary: perl-XML-LibXSLT-1.73 is available Product: Fedora Version: rawhide Platform: Unspecified OS/Version: Unspecified Status: NEW Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Component: perl-XML-LibXSLT AssignedTo: mmasl...@redhat.com ReportedBy: upstream-release-monitor...@fedoraproject.org QAContact: extras...@fedoraproject.org CC: z...@fastmail.fm, fedora-perl-devel-l...@redhat.com, mmasl...@redhat.com Classification: Fedora Story Points: --- Type: --- Latest upstream release: 1.73 Current version in Fedora Rawhide: 1.72 URL: http://search.cpan.org/dist/XML-LibXSLT/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 744553] perl-POE-Component-IRC-6.73 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=744553 --- Comment #2 from Petr Sabata psab...@redhat.com 2011-10-11 06:49:47 EDT --- *** Bug 745071 has been marked as a duplicate of this bug. *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 745071] perl-POE-Component-IRC-6.74 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=745071 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED CC||psab...@redhat.com Resolution||DUPLICATE Last Closed||2011-10-11 06:49:47 --- Comment #1 from Petr Sabata psab...@redhat.com 2011-10-11 06:49:47 EDT --- *** This bug has been marked as a duplicate of bug 744553 *** -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 745072] perl-XML-LibXSLT-1.73 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=745072 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||psab...@redhat.com AssignedTo|mmasl...@redhat.com |psab...@redhat.com -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File XML-LibXSLT-1.73.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-XML-LibXSLT: 99b372c85cae773a073d4387e305c29c XML-LibXSLT-1.73.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-XML-LibXSLT] 1.73 bump
commit 6b0d7e96ef4b659f43e7dc57f4db8c2aec04da39
Author: Petr Sabata con...@redhat.com
Date: Tue Oct 11 12:56:20 2011 +0200
1.73 bump
.gitignore|1 +
perl-XML-LibXSLT.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 91131f6..4b15b39 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
XML-LibXSLT-1.70.tar.gz
/XML-LibXSLT-1.71.tar.gz
/XML-LibXSLT-1.72.tar.gz
+/XML-LibXSLT-1.73.tar.gz
diff --git a/perl-XML-LibXSLT.spec b/perl-XML-LibXSLT.spec
index 4292184..ecd98f9 100644
--- a/perl-XML-LibXSLT.spec
+++ b/perl-XML-LibXSLT.spec
@@ -1,6 +1,6 @@
Name: perl-XML-LibXSLT
# NOTE: also update perl-XML-LibXML to a compatible version. See below why.
-Version: 1.72
+Version: 1.73
Release: 1%{?dist}
Summary: Perl module for interfacing to GNOME's libxslt
Group: Development/Libraries
@@ -49,6 +49,9 @@ make test
%{_mandir}/man3/*.3*
%changelog
+* Tue Oct 11 2011 Petr Sabata con...@redhat.com - 1.73-1
+- 1.73 bump
+
* Fri Oct 07 2011 Petr Sabata con...@redhat.com - 1.72-1
- 1.72 bump
- benchmark.pl moved to benchmark/
diff --git a/sources b/sources
index c6fd0d1..f779ab9 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-574c5d44749517af18faf1911a010547 XML-LibXSLT-1.72.tar.gz
+99b372c85cae773a073d4387e305c29c XML-LibXSLT-1.73.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 745072] perl-XML-LibXSLT-1.73 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=745072 Petr Sabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-XML-LibXSLT-1.73-1.fc1 ||7 Resolution||RAWHIDE Last Closed||2011-10-11 07:00:44 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 745070] perl-DateTime-TimeZone-1.40 is available
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=745070 Iain Arnell iarn...@gmail.com changed: What|Removed |Added Status|NEW |CLOSED Resolution||RAWHIDE Last Closed||2011-10-11 07:13:18 --- Comment #1 from Iain Arnell iarn...@gmail.com 2011-10-11 07:13:18 EDT --- Already in rawhide and bodhi https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.40-1.fc14 https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.40-1.fc15 https://admin.fedoraproject.org/updates/perl-DateTime-TimeZone-1.40-1.fc16 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Pugs-Compiler-Rule
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree: On x86_64: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) On i386: perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires perl(:MODULE_COMPAT_5.12.3) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File SQL-Translator-0.11010.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-SQL-Translator: 4a1578519f535f5df19deae8e3661242 SQL-Translator-0.11010.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 745337] New: amavisd doesn't start in fc15
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. Summary: amavisd doesn't start in fc15 https://bugzilla.redhat.com/show_bug.cgi?id=745337 Summary: amavisd doesn't start in fc15 Product: Fedora Version: 15 Platform: All OS/Version: Linux Status: NEW Severity: medium Priority: unspecified Component: amavisd-new AssignedTo: st...@silug.org ReportedBy: i...@ekit-inc.com QAContact: extras...@fedoraproject.org CC: st...@silug.org, fedora-perl-devel-l...@redhat.com, kana...@kanarip.com Classification: Fedora Story Points: --- Type: --- Description of problem: amavisd doesn't start at boot as /var/run/amavisd as installed by the rpm doesn't exist after reboot as /var/run is a tmpfs in fc15 Version-Release number of selected component (if applicable): amavisd-new-2.6.6-1.fc15.noarch How reproducible: 100% Steps to Reproduce: 1. chkconfig amavisd on; then configure it; reboot 2. 3. Actual results: ps -ef|grep amavisd shows it isn't running Expected results: running Additional info: $ rpm -ql amavisd-new |grep /var/run /var/run/amavisd /var/run/clamd.amavisd My workaround was to add an additional rc script run before amavisd -- $ ll /etc/*.d/*amavisd_kludge -r-xr-xr-x. 1 root root 366 Sep 14 08:57 /etc/init.d/amavisd_kludge -r-xr-xr-x. 1 root root 366 Sep 14 08:57 /etc/rc3.d/S77amavisd_kludge $ cat /etc/init.d/amavisd_kludge #! /bin/sh if [ -d /var/run/amavisd ] then : else mkdir /var/run/amavisd chown amavis:amavis /var/run/amavisd chmod 755 /var/run/amavisd restorecon -Rv /var/run/amavisd fi $ -- but this should probably be added to the /etc/init.d/amavisd script. In my situation I didn't require /var/run/clamd.amavisd to exist as my clamd.pid is configured to be in /var/run/amavisd/clamd.pid but for completeness the amavisd startup script probably should also create /var/run/clamd.amavisd -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-SQL-Translator] update to 0.11010
commit e72dbebe47841db79d21b53c03ba161c85924e92
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 12 05:40:08 2011 +0200
update to 0.11010
.gitignore |1 +
perl-SQL-Translator.spec | 26 ++
sources |2 +-
3 files changed, 12 insertions(+), 17 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 49d48f2..8a5f115 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
SQL-Translator-0.11005.tar.gz
/SQL-Translator-0.11006.tar.gz
+/SQL-Translator-0.11010.tar.gz
diff --git a/perl-SQL-Translator.spec b/perl-SQL-Translator.spec
index dbf19b6..1f7b9ff 100644
--- a/perl-SQL-Translator.spec
+++ b/perl-SQL-Translator.spec
@@ -1,12 +1,11 @@
Name: perl-SQL-Translator
Summary:Manipulate structured data definitions (SQL and more)
-Version:0.11006
-Release:6%{?dist}
+Version:0.11010
+Release:1%{?dist}
License:GPLv2
Group: Development/Libraries
-Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/SQL-Translator-%{version}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/J/JR/JROBINSON/SQL-Translator-%{version}.tar.gz
URL:http://search.cpan.org/dist/SQL-Translator/
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
BuildArch: noarch
@@ -30,8 +29,10 @@ BuildRequires: perl(IO::File)
BuildRequires: perl(IO::Scalar) = 2.11
BuildRequires: perl(Log::Log4perl)
BuildRequires: perl(Module::Build)
+BuildRequires: perl(Moo) = 0.009007
BuildRequires: perl(Parse::RecDescent) = 1.963
BuildRequires: perl(Pod::Usage)
+BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Spreadsheet::ParseExcel)
BuildRequires: perl(Template)
BuildRequires: perl(Test::Differences)
@@ -44,19 +45,13 @@ BuildRequires: perl(XML::Writer) = 0.5
BuildRequires: perl(XML::XPath)
BuildRequires: perl(YAML) = 0.66
-Requires: perl(Carp::Clan)
-Requires: perl(Class::Accessor::Fast)
-Requires: perl(Class::Base)
Requires: perl(Class::Data::Inheritable) = 0.02
Requires: perl(Class::MakeMethods)
-Requires: perl(DBI)
Requires: perl(Digest::SHA1) = 2
Requires: perl(File::ShareDir) = 1
Requires: perl(File::Spec)
-Requires: perl(IO::Dir)
Requires: perl(IO::Scalar) = 2.11
Requires: perl(Parse::RecDescent) = 1.963
-Requires: perl(Pod::Usage)
Requires: perl(XML::Writer) = 0.5
@@ -93,8 +88,6 @@ perl -pi -e 's|^#!/usr/local/bin/perl|#!%{__perl}|' t/*.t
make %{?_smp_mflags}
%install
-rm -rf %{buildroot}
-
make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} +
@@ -106,17 +99,18 @@ find %{buildroot} -depth -type d -exec rmdir {}
2/dev/null \;
%check
make test
-%clean
-rm -rf %{buildroot}
-
%files
-%defattr(-,root,root,-)
%doc AUTHORS BUGS Changes LICENSE README
%{_bindir}/*
%{perl_vendorlib}/*
%{_mandir}/man[13]/*
%changelog
+* Wed Oct 12 2011 Iain Arnell iarn...@gmail.com 0.11010-1
+- update to latest upstream version
+- clean up spec for modern rpmbuild
+- remove unnecessary explicit requires
+
* Thu Jul 21 2011 Iain Arnell iarn...@gmail.com 0.11006-6
- update filtering for rpm 4.9
diff --git a/sources b/sources
index 621afe7..10aca04 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-27f06358cb8c34447deb845d8ab9ba1e SQL-Translator-0.11006.tar.gz
+4a1578519f535f5df19deae8e3661242 SQL-Translator-0.11010.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Carp-REPL-0.15.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Carp-REPL: 89b98f874cb3d0b4ede1363dcb3baa1e Carp-REPL-0.15.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-Carp-REPL] initial import (rhbz#742556)
commit c8d886d4e1e2b1f77d4bc1c43d988ca9613a5af1
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 12 06:20:07 2011 +0200
initial import (rhbz#742556)
.gitignore |1 +
perl-Carp-REPL.spec | 68 +++
sources |1 +
3 files changed, 70 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..88f2f9d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Carp-REPL-0.15.tar.gz
diff --git a/perl-Carp-REPL.spec b/perl-Carp-REPL.spec
new file mode 100644
index 000..bb43c3e
--- /dev/null
+++ b/perl-Carp-REPL.spec
@@ -0,0 +1,68 @@
+Name: perl-Carp-REPL
+Version:0.15
+Release:2%{?dist}
+Summary:Read-eval-print-loop on die and/or warn
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Carp-REPL/
+Source0:
http://www.cpan.org/authors/id/S/SA/SARTAK/Carp-REPL-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Data::Dump::Streamer)
+BuildRequires: perl(Devel::LexAlias)
+BuildRequires: perl(Devel::REPL)
+BuildRequires: perl(Devel::StackTrace::WithLexicals)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Lexical::Persistence)
+BuildRequires: perl(namespace::clean)
+BuildRequires: perl(Test::Expect)
+BuildRequires: perl(Test::More)
+Requires: perl(Devel::REPL)
+Requires: perl(Lexical::Persistence)
+Requires: perl(namespace::clean)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+# Test::Expect and/or Devel::REPL is failing under mock 1.1.8 in koji
+# all is fine locally with mock 1.1.14, though
+%bcond_with expect_tests
+
+%{?perl_default_filter}
+
+%description
+Carp-REPL is a debugging aid for Perl programs. When a program dies (or warns),
+you get a REPL instead of dying or continuing blindly.
+
+%prep
+%setup -q -n Carp-REPL-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+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
+# Test::Expect and/or Devel::REPL is failing under mock 1.1.8 in koji
+# all is fine locally with mock 1.1.14, though
+%if ! %{with expect_tests}
+grep -lZ 'Test::Expect' t/*.t |xargs -0 rm -f
+%endif
+make test
+
+%files
+%doc Changes
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Oct 04 2011 Iain Arnell iarn...@gmail.com 0.15-2
+- Test::Expect and/or Devel::REPL fail under mock 1.1.8 in koji
+ use --with expect-tests to enable locally
+
+* Fri Sep 30 2011 Iain Arnell iarn...@gmail.com 0.15-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..b0a1c95 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+89b98f874cb3d0b4ede1363dcb3baa1e Carp-REPL-0.15.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-Math-BigInt-GMP] rebuild with new gmp
commit a291db4f33b5f8a29c227f56136c59f56248fe4f
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Oct 12 06:21:20 2011 +0200
rebuild with new gmp
perl-Math-BigInt-GMP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Math-BigInt-GMP.spec b/perl-Math-BigInt-GMP.spec
index b1eb1f9..62e4954 100644
--- a/perl-Math-BigInt-GMP.spec
+++ b/perl-Math-BigInt-GMP.spec
@@ -1,6 +1,6 @@
Name: perl-Math-BigInt-GMP
Version:1.36
-Release:2%{?dist}
+Release:2%{?dist}.1
Summary:Math::BigInt::GMP Perl module
License:GPL+ or Artistic
Group: Development/Libraries
@@ -51,6 +51,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Oct 12 2011 Peter Schiffer pschi...@redhat.com - 1.36-2.1
+- rebuild with new gmp
+
* Mon Jun 20 2011 Marcela Mašláňová mmasl...@redhat.com - 1.36-2
- Perl mass rebuild
--
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 CatalystX-Profile-0.02.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CatalystX-Profile: 708ab56ebf8707c1668b1a48f3518c2f CatalystX-Profile-0.02.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-CatalystX-Profile] initial import (rhbz#742557)
commit da8a286c428967117a8ca88d23952c6ebb884e40
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 12 06:22:14 2011 +0200
initial import (rhbz#742557)
.gitignore |1 +
perl-CatalystX-Profile.spec | 59 +++
sources |1 +
3 files changed, 61 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..d975479 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/CatalystX-Profile-0.02.tar.gz
diff --git a/perl-CatalystX-Profile.spec b/perl-CatalystX-Profile.spec
new file mode 100644
index 000..65b8497
--- /dev/null
+++ b/perl-CatalystX-Profile.spec
@@ -0,0 +1,59 @@
+Name: perl-CatalystX-Profile
+Version:0.02
+Release:1%{?dist}
+Summary:Profile your Catalyst application with Devel::NYTProf
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/CatalystX-Profile/
+Source0:
http://www.cpan.org/authors/id/J/JJ/JJNAPIORK/CatalystX-Profile-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Catalyst::Runtime) = 5.80020
+BuildRequires: perl(CatalystX::InjectComponent) = 0.024
+BuildRequires: perl(Devel::NYTProf) = 3.01
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Moose) = 0.93
+BuildRequires: perl(namespace::autoclean) = 0.09
+BuildRequires: perl(Sub::Identify) = 0.04
+BuildRequires: perl(Test::More)
+Requires: perl(Catalyst::Runtime) = 5.80020
+Requires: perl(CatalystX::InjectComponent) = 0.024
+Requires: perl(Devel::NYTProf) = 3.01
+Requires: perl(Moose) = 0.93
+Requires: perl(namespace::autoclean) = 0.09
+Requires: perl(Sub::Identify) = 0.04
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This (really basic for now) plugin adds support for profiling your Catalyst
+application, without profiling all the crap that happens during setup. This
+noise can make finding the real profiling stuff trickier, so profiling is
+disabled while this happens.
+
+%prep
+%setup -q -n CatalystX-Profile-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+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
+make test
+
+%files
+%doc LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Sep 30 2011 Iain Arnell iarn...@gmail.com 0.02-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..d79335e 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+708ab56ebf8707c1668b1a48f3518c2f CatalystX-Profile-0.02.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Catalyst-Plugin-Session-Store-DBIC-0.12.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-Catalyst-Plugin-Session-Store-DBIC: ae13f2cbae763eef1bbad7abcd4f618d Catalyst-Plugin-Session-Store-DBIC-0.12.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-Catalyst-Plugin-Session-Store-DBIC] initial import (rhbz#742555)
commit 6e1be019b2a42025be676adbdccea33b53abc0b6
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 12 06:23:33 2011 +0200
initial import (rhbz#742555)
.gitignore |1 +
perl-Catalyst-Plugin-Session-Store-DBIC.spec | 67 ++
sources |1 +
3 files changed, 69 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..61d9c86 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Catalyst-Plugin-Session-Store-DBIC-0.12.tar.gz
diff --git a/perl-Catalyst-Plugin-Session-Store-DBIC.spec
b/perl-Catalyst-Plugin-Session-Store-DBIC.spec
new file mode 100644
index 000..eab09e9
--- /dev/null
+++ b/perl-Catalyst-Plugin-Session-Store-DBIC.spec
@@ -0,0 +1,67 @@
+Name: perl-Catalyst-Plugin-Session-Store-DBIC
+Version:0.12
+Release:1%{?dist}
+Summary:Store your sessions via DBIx::Class
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Catalyst-Plugin-Session-Store-DBIC/
+Source0:
http://www.cpan.org/authors/id/F/FL/FLORA/Catalyst-Plugin-Session-Store-DBIC-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(Catalyst) = 5.65000
+BuildRequires: perl(Catalyst::Exception)
+BuildRequires: perl(Catalyst::Model::DBIC::Schema)
+BuildRequires: perl(Catalyst::Plugin::Session::State::Cookie)
+BuildRequires: perl(Catalyst::Plugin::Session::Store::Delegate) = 0.05
+BuildRequires: perl(Class::Accessor::Fast)
+BuildRequires: perl(DBD::SQLite)
+BuildRequires: perl(DBIx::Class) = 0.07000
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(MIME::Base64)
+BuildRequires: perl(MRO::Compat)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Storable)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(Test::Warn) = 0.20
+BuildRequires: perl(Test::WWW::Mechanize::Catalyst)
+Requires: perl(Catalyst) = 5.65000
+Requires: perl(DBIx::Class) = 0.07000
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+This Catalyst::Plugin::Session storage module saves session data in your
+database via DBIx::Class. It's actually just a wrapper around
+Catalyst::Plugin::Session::Store::Delegate; if you need complete control
+over how your sessions are stored, you probably want to use that instead.
+
+%prep
+%setup -q -n Catalyst-Plugin-Session-Store-DBIC-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+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
+TEST_POD=1 make test
+
+%files
+%doc Changes
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Sep 30 2011 Iain Arnell iarn...@gmail.com 0.12-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..6d1f91d 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+ae13f2cbae763eef1bbad7abcd4f618d
Catalyst-Plugin-Session-Store-DBIC-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File CatalystX-SimpleLogin-0.15.tar.gz uploaded to lookaside cache by iarnell
A file has been added to the lookaside cache for perl-CatalystX-SimpleLogin: 1ed6869bb214f012c8594f8096d528f4 CatalystX-SimpleLogin-0.15.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-CatalystX-SimpleLogin] initial import (rhbz#742560)
commit 748961cea143aad8bc9d11065984ce159f367c2e
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 12 06:24:41 2011 +0200
initial import (rhbz#742560)
.gitignore |1 +
perl-CatalystX-SimpleLogin.spec | 91 +++
sources |1 +
3 files changed, 93 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..10eee45 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/CatalystX-SimpleLogin-0.15.tar.gz
diff --git a/perl-CatalystX-SimpleLogin.spec b/perl-CatalystX-SimpleLogin.spec
new file mode 100644
index 000..2374f00
--- /dev/null
+++ b/perl-CatalystX-SimpleLogin.spec
@@ -0,0 +1,91 @@
+Name: perl-CatalystX-SimpleLogin
+Version:0.15
+Release:1%{?dist}
+Summary:Provide a simple Login controller which can be reused
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/CatalystX-SimpleLogin/
+Source0:
http://www.cpan.org/authors/id/B/BO/BOBTFISH/CatalystX-SimpleLogin-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Catalyst::Action::RenderView)
+BuildRequires: perl(Catalyst::Action::REST) = 0.74
+BuildRequires: perl(Catalyst::ActionRole::ACL)
+# not available in fedora and upstream is currently broken
+# see https://rt.cpan.org/Public/Bug/Display.html?id=70417
+# BuildRequires: perl(Catalyst::Authentication::Credential::OpenID)
+BuildRequires: perl(Catalyst::Authentication::Store::DBIx::Class)
+BuildRequires: perl(Catalyst::Controller::ActionRole) = 0.12
+BuildRequires: perl(Catalyst::Model::DBIC::Schema)
+BuildRequires: perl(Catalyst::Plugin::Authentication)
+BuildRequires: perl(Catalyst::Plugin::Session) = 0.27
+BuildRequires: perl(Catalyst::Plugin::Session::State::Cookie)
+BuildRequires: perl(Catalyst::Plugin::Session::Store::File)
+BuildRequires: perl(Catalyst::Runtime) = 5.80013
+BuildRequires: perl(Catalyst::View::TT)
+BuildRequires: perl(CatalystX::Component::Traits) = 0.13
+BuildRequires: perl(CatalystX::InjectComponent)
+BuildRequires: perl(Crypt::DH)
+BuildRequires: perl(DBD::SQLite)
+BuildRequires: perl(DBIx::Class::Optional::Dependencies)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(HTML::FormHandler) = 0.28001
+BuildRequires: perl(HTTP::Request::Common)
+BuildRequires: perl(JSON::Any) = 1.22
+BuildRequires: perl(Moose)
+BuildRequires: perl(Moose::Autobox)
+BuildRequires: perl(MooseX::MethodAttributes) = 0.18
+BuildRequires: perl(MooseX::RelatedClassRoles) = 0.004
+BuildRequires: perl(MooseX::Types)
+BuildRequires: perl(MooseX::Types::Common)
+BuildRequires: perl(MooseX::Types::JSON) = 0.02
+BuildRequires: perl(MooseX::Types::Path::Class) = 0.05
+BuildRequires: perl(namespace::autoclean)
+BuildRequires: perl(SQL::Translator)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More) = 0.94
+Requires: perl(Catalyst::Action::REST) = 0.74
+Requires: perl(Catalyst::Plugin::Authentication)
+Requires: perl(Catalyst::Plugin::Session) = 0.27
+Requires: perl(Catalyst::Runtime) = 5.80013
+Requires: perl(Catalyst::View::TT)
+Requires: perl(CatalystX::Component::Traits) = 0.13
+Requires: perl(HTML::FormHandler) = 0.28001
+Requires: perl(MooseX::MethodAttributes) = 0.18
+Requires: perl(MooseX::RelatedClassRoles) = 0.004
+Requires: perl(MooseX::Types)
+Requires: perl(MooseX::Types::Common)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+CatalystX::SimpleLogin is an application class which provides a simple login
+and logout page with the adition of only one line of code and one template to
+your application.
+
+%prep
+%setup -q -n CatalystX-SimpleLogin-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+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
+make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Fri Sep 30 2011 Iain Arnell iarn...@gmail.com 0.15-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..9fcbafd 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+1ed6869bb214f012c8594f8096d528f4 CatalystX-SimpleLogin-0.15.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-CatalystX-SimpleLogin] fix spelling in description
commit fc9e3c6601e2ba032e2fa5cf6876b2df594cc4a4
Author: Iain Arnell iarn...@gmail.com
Date: Wed Oct 12 06:25:13 2011 +0200
fix spelling in description
perl-CatalystX-SimpleLogin.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-CatalystX-SimpleLogin.spec b/perl-CatalystX-SimpleLogin.spec
index 2374f00..32cebf4 100644
--- a/perl-CatalystX-SimpleLogin.spec
+++ b/perl-CatalystX-SimpleLogin.spec
@@ -1,6 +1,6 @@
Name: perl-CatalystX-SimpleLogin
Version:0.15
-Release:1%{?dist}
+Release:2%{?dist}
Summary:Provide a simple Login controller which can be reused
License:GPL+ or Artistic
Group: Development/Libraries
@@ -60,7 +60,7 @@ Requires: perl(:MODULE_COMPAT_%(eval `%{__perl}
-V:version`; echo $versi
%description
CatalystX::SimpleLogin is an application class which provides a simple login
-and logout page with the adition of only one line of code and one template to
+and logout page with the addition of only one line of code and one template to
your application.
%prep
@@ -87,5 +87,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Wed Oct 12 2011 Iain Arnell iarn...@gmail.com 0.15-2
+- fix spelling in description
+
* Fri Sep 30 2011 Iain Arnell iarn...@gmail.com 0.15-1
- Specfile autogenerated by cpanspec 1.78.
--
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-Math-GMP] rebuild with new gmp
commit 68c6ce2e8a28e908b3f7d94eac90820895f35768
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Wed Oct 12 06:27:04 2011 +0200
rebuild with new gmp
perl-Math-GMP.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-Math-GMP.spec b/perl-Math-GMP.spec
index 17ae2c4..2414c0f 100644
--- a/perl-Math-GMP.spec
+++ b/perl-Math-GMP.spec
@@ -1,7 +1,7 @@
Summary: High speed arbitrary size integer math
Name: perl-Math-GMP
Version: 2.06
-Release: 8%{?dist}
+Release: 8%{?dist}.1
License: LGPLv2+
Group: Development/Libraries
Url: http://search.cpan.org/dist/Math-GMP/
@@ -94,6 +94,9 @@ rm -rf %{buildroot}
%{_mandir}/man3/Math::GMP.3pm*
%changelog
+* Wed Oct 12 2011 Peter Schiffer pschi...@redhat.com - 2.06-8.1
+- rebuild with new gmp
+
* Wed Jul 20 2011 Paul Howarth p...@city-fan.org 2.06-8
- Perl mass rebuild
- Work around MYMETA.yml causing signature test to fail
--
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
