EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 867 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 322 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 86 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 77 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1696/perl-Email-Address-1.905-1.el5 71 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1747/mediawiki119-1.19.17-1.el5 29 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2153/drupal6-6.33-1.el5 29 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2150/drupal7-7.31-1.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2269/GraphicsMagick-1.3.20-3.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2304/xine-lib-1.1.21-10.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2308/python-elixir-0.5.0-2.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2424/389-ds-base-1.2.11.32-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing 389-ds-base-1.2.11.32-1.el5 etckeeper-1.14-1.el5 fedora-easy-karma-0-0.23.20140905git5fb5b77a.el5 libcutl-1.8.1-1.el5 pcp-3.9.10-1.el5 pdfcrack-0.14-1.el5 pem-0.7.9-7.el5 Details about builds: 389-ds-base-1.2.11.32-1.el5 (FEDORA-EPEL-2014-2424) 389 Directory Server (base) Update Information: 389-ds-base-1.2.11.32 release - several bug fixes ChangeLog: * Thu Sep 4 2014 Noriko Hosoi nho...@redhat.com - 1.2.11.32-1 - bump version to 1.2.11.32 - Ticket 47875 - dirsrv not running with old openldap - Ticket 47457 - default nsslapd-sasl-max-buffer-size should be 2MB * Tue Sep 2 2014 Noriko Hosoi nho...@redhat.com - 1.2.11.31-1 - bump version to 1.2.11.31 - Bug 1129660 - Adding users to user group throws Internal server error. - Ticket 47875 - dirsrv not running with old openldap - Ticket 47446 - logconv.pl memory continually grows - Ticket 443 - Deleting attribute present in nsslapd-allowed-to-delete-attrs returns Operations error - Ticket 415 - winsync doesn't sync DN valued attributes if DS DN value doesn't exist - Ticket 47874 - Performance degradation with scope ONE after some load - Ticket 47872 - Filter AND with only one clause should be optimized * Thu Aug 7 2014 Noriko Hosoi nho...@redhat.com - 1.2.11.30-1 - bump version to 1.2.11.30 - Resolves: #1123477 Ticket 47869 - unauthenticated information disclosure (Bug 1123477) - Ticket 616 - High contention on computed attribute lock - Ticket 47862 - repl-monitor fails to convert * to default values - Ticket 47824 - paged results control is not working in some cases when we have a subsuffix. - Ticket 47862 - Repl-monitor.pl ignores the provided connection parameters - Ticket 346 - Fixing memory leaks - Ticket 443 - Deleting attribute present in nsslapd-allowed-to-delete-attrs returns Operations error - Ticket 47863 - New defects found in 389-ds-base-1.2.11 - Ticket 47861 - Certain schema files are not replaced during upgrade - Ticket 47858 - Internal searches using OP_FLAG_REVERSE_CANDIDATE_ORDER can crash the server - Ticket 47692 - single valued attribute replicated ADD does not work - Ticket 47781 - Server deadlock if online import started while server is under load - Ticket 47821 - deref plugin cannot handle complex acis - Ticket 47831 - server restart wipes out index config if there is a default index - Ticket 47820 - 1.2.11 branch: coverity errors - Ticket 47817 - The error result text message should be obtained just prior to sending result - Ticket 47331 - Self entry access ACI not working properly - Ticket 47426 - Coverity issue with last commit(move compute_idletimeout out of handle_pr_read_ready) - Ticket 47426 - move compute_idletimeout out of handle_pr_read_ready - Ticket 47809 - find a way to remove replication plugin errors messages changelog iteration code returned a dummy entry with csn %s, skipping ... - Ticket 47813 - remove goto bail from previous commit - Ticket 47813 - managed entry plugin fails to update member pointer on modrdn operation - Ticket 47770 - #481 breaks possibility to reassemble memberuid list - Ticket 47446 - logconv.pl memory continually grows - Ticket 47713 - Logconv.pl with an empty access log gives lots of errors - Ticket 47670 - Aci warnings in error log - Ticket 47804 - db2bak.pl error with changelogdb - Ticket 47780 - Some VLV search request causes memory leaks - Ticket 47787 - A replicated MOD fails (Unwilling to perform) if it targets a tombstone - Ticket 47764 - Problem with deletion while replicated - Ticket 47750 - Creating a glue fails if one above
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 867 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 199 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 86 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 77 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1693/perl-Email-Address-1.905-1.el6 36 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2099/v8-3.14.5.10-11.el6 29 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2148/drupal6-6.33-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2310/Django14-1.4.14-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2299/libmodplug-0.8.8.5-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2257/GraphicsMagick-1.3.20-3.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2302/xine-lib-1.1.21-10.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing ceph-0.80.5-9.el6 cups-bjnp-2.0-1.el6 etckeeper-1.14-1.el6 fedora-easy-karma-0-0.23.20140905git5fb5b77a.el6 libcutl-1.8.1-1.el6 pcp-3.9.10-1.el6 php-horde-Horde-Imap-Client-2.25.0-1.el6 python-augeas-0.5.0-1.el6 python-docker-registry-core-2.0.1-2.el6 unbound-1.4.22-1.el6 Details about builds: ceph-0.80.5-9.el6 (FEDORA-EPEL-2014-2240) User space components of the Ceph file system Update Information: We need to downgrade the package to the latest stable version for epel 6, too. This package also fixes many spec file bugs (several of them filed against rawhide). References: [ 1 ] Bug #1017495 - pkg Requires: ceph-disk utility imports 'argparse' module https://bugzilla.redhat.com/show_bug.cgi?id=1017495 [ 2 ] Bug #1030402 - mount.ceph helper in wrong directory https://bugzilla.redhat.com/show_bug.cgi?id=1030402 [ 3 ] Bug #1109895 - missing librbd symlink to enable CEPH support in qemu-kvm-rhev https://bugzilla.redhat.com/show_bug.cgi?id=1109895 cups-bjnp-2.0-1.el6 (FEDORA-EPEL-2014-2426) CUPS backend for the Canon BJNP network printers Update Information: New upstream release 2.0 Adds ink level reporting improved printer error handling ChangeLog: * Sat Sep 6 2014 Louis Lagendijk llagend...@users.sourceforge.net - 1.9.2-1 - New upstream release 2.0 - Adds ink level reporting - improved printer error handling * Sat Aug 16 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.9.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.9.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Sat Apr 12 2014 Louis Lagendijk llagend...@users.sourceforge.net - 1.9.2-1 - New upstream release 1.9.2 - Simplified error handling * Sat Mar 29 2014 Louis Lagendijk llagend...@users.sourceforge.net - 1.9.1-1 - New upstream release 1.9.1 - fixes out of paper reporting - Fixes an incompatibility with xml status reports from newer printers * Thu Mar 20 2014 Louis Lagendijk llagend...@users.sourceforge.net - 1.9.0-1 - New upstream release 1.9.0 - Adds ink-level reporting - improved out-of-paper handling etckeeper-1.14-1.el6 (FEDORA-EPEL-2014-2419) Store /etc in a SCM system (git, mercurial, bzr or darcs) Update Information: Update to the latest stable version. Upstream changelog: * Handle failure to commit in post-install, pre-install by showing a warning, rather than propigating the error to apt. This avoids breaking the apt run when eg, git is misconfigured and cannot commit. pre-install already did this when it was able to use debconf to display a message, but now debconf is not used, and it always behaves this way. Closes: http://bugs.debian.org/760011 ChangeLog: * Fri Sep 5 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.14-1 - Update to 1.14.
Re: blivet-gui announcement
On Fri, 2014-09-05 at 18:03 +0200, Lennart Poettering wrote: On Fri, 05.09.14 11:52, Matthias Clasen (mcla...@redhat.com) wrote: On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is why not gnome-disk-utility? :) Because it doesn't work well with LVM, RAID, BTRFS and a combination of them. Leaving LVM out was an explicit decision, because of all the system integration problems with LVM. It works fine with RAID and btrfs as far as I know. Do you have any concrete complaints about the RAID or btrfs support in gnome-disk-utility ? Also, note that gnome-disk-utility actually properly separates out the unpriviliged UI from the priviliged backend in udisks. In this day-and-age we should not write new programs anymore that require the entire UI stack to run as root. We should really get away from doing something like that. In the blivet-ui docs su is the recommended way to invoke the program, and that's really wrong for a graphical one. gnome-disk-utility got that right. the new blivet ui did not. And this is not something you can add as an afterthought, you actually need to do your homework and split things up into privileged and non-priviliged parts from the beginning. The blivet-ui thing in this regard is certainly not an improvement over g-d-u, it's a step back. Well...I agree that in perfect theoretical engineering land, it'd be nice if blivet-gui had a better privilege model. I think you're being way too unnecessarily harsh, though, and missing a rather major point. blivet-gui is not 100% new code. The new bit is just the relatively thin GUI wrapper. The really hard code - the bits that do the partitioning - has existed for 15+ years: it's anaconda's partitioning code (lately split out into python-blivet). And that code has *always* assumed it'll run as root, because it's part of an installer that always does. If you want to use the blivet code as the base for a standalone GUI installer and add a better privilege model, that was always going to be a retrofitting job - even if you did it before doing this initial 0.1.x release of blivet-gui, you're still retrofitting. It's really not a significant difference. I can believe it'd be hard work, but I think you overstate the case by a long way when you say it'd be impossible. It may be finicky work, but it seems unlikely that it'd be easier to write an entirely new partitioning app with all of blivet's capabilities from the ground up (with a good privilege model) than it would be to take advantage of all that existing code for doing the very difficult and complex work of partitioning, and retrofit a decent privilege model onto it. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Fri, 2014-09-05 at 11:52 -0400, Matthias Clasen wrote: On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is why not gnome-disk-utility? :) Because it doesn't work well with LVM, RAID, BTRFS and a combination of them. Leaving LVM out was an explicit decision, because of all the system integration problems with LVM. It works fine with RAID No, it doesn't: https://git.gnome.org/browse/gnome-disk-utility/commit/?id=820e2d3d325aef3574e207a5df73e7480ed41dda the RAID support was entirely removed with that commit. and btrfs as far as I know. Do you have any concrete complaints about the RAID or btrfs support in gnome-disk-utility ? So far as btrfs goes - well, I wouldn't say complaints, but it's not at all in the same capability league as blivet. I just booted a current F21 nightly (so, current gnome-disks code) and the extent of its ability to create new btrfs filesystems seems to be 'you can format a partition, pick Custom as the Type, and set it to btrfs'. That's fine so far as it goes, but it's a long way from really 'supporting' btrfs. btrfs isn't a simple filesystem like FAT or NTFS or ext or xfs. It's more of an all-singing, all-dancing combined filesystem/volume management/redundancy/kitchen sink arrangement. blivet actually understands all of this, it really *supports* btrfs: you can create btrfs volumes that span multiple disks, configure a lot of their attributes, and create and configure subvolumes within the volumes. Unless I'm missing something, gnome-disks does none of that. Honestly I don't see that gnome-disks and blivet-gui would be entirely playing in the same sandbox. It might be viable to think of them as GNOME's 'Network' control panel applet vs. nm-connection-editor, or something along those lines? But probably with even more of a difference. I like GNOME Disks, it's a great handy toolbox for doing simple manipulation of drives, but I'm not sure it quite fits the same mental box as blivet-gui would, for me. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Sat, Sep 6, 2014 at 8:57 AM, Adam Williamson adamw...@fedoraproject.org wrote: On Fri, 2014-09-05 at 11:52 -0400, Matthias Clasen wrote: On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is why not gnome-disk-utility? :) Because it doesn't work well with LVM, RAID, BTRFS and a combination of them. Leaving LVM out was an explicit decision, because of all the system integration problems with LVM. It works fine with RAID No, it doesn't: https://git.gnome.org/browse/gnome-disk-utility/commit/?id=820e2d3d325aef3574e207a5df73e7480ed41dda the RAID support was entirely removed with that commit. and btrfs as far as I know. Do you have any concrete complaints about the RAID or btrfs support in gnome-disk-utility ? So far as btrfs goes - well, I wouldn't say complaints, but it's not at all in the same capability league as blivet. I just booted a current F21 nightly (so, current gnome-disks code) and the extent of its ability to create new btrfs filesystems seems to be 'you can format a partition, pick Custom as the Type, and set it to btrfs'. That's fine so far as it goes, but it's a long way from really 'supporting' btrfs. btrfs isn't a simple filesystem like FAT or NTFS or ext or xfs. It's more of an all-singing, all-dancing combined filesystem/volume management/redundancy/kitchen sink arrangement. blivet actually understands all of this, it really *supports* btrfs: you can create btrfs volumes that span multiple disks, configure a lot of their attributes, and create and configure subvolumes within the volumes. Unless I'm missing something, gnome-disks does none of that. Honestly I don't see that gnome-disks and blivet-gui would be entirely playing in the same sandbox. It might be viable to think of them as GNOME's 'Network' control panel applet vs. nm-connection-editor, or something along those lines? But probably with even more of a difference. I like GNOME Disks, it's a great handy toolbox for doing simple manipulation of drives, but I'm not sure it quite fits the same mental box as blivet-gui would, for me. Yeah I don't think its an issue to have multiple applications for the same purpose. We have more than one app for pretty much all other tasks. As for the privileged vs. unprivileged ... that should be fixed. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Friday 05 September 2014 23:57:46 Adam Williamson wrote: I like GNOME Disks, it's a great handy toolbox for doing simple manipulation of drives, but I'm not sure it quite fits the same mental box as blivet-gui would, for me. So, to extend the theoretical POV the way to go may have been: * Make the backend (udisks or equivalent) use python-blivet for a complete partitioning stack. * Let GNOME Disks expose only a naive-user-friendly subset of the functionality. * Let a full blivet-ui expose the full functionality. (obviously it's easier for me to do the talk than do the walk ;-) On another related front, can anyone relate this to similar technologies: * SystemStorageManager (https://fedoraproject.org/wiki/Features/SystemStorageManager) * openlmi-storage (https://git.fedorahosted.org/git/openlmi-storage.git) * The last one is even implemented in python. Just to make clear -- I think multiple competing solutions in the same domain are totally OK, especially when it's not clear which technologies will get traction. So even though running UI's as root is really bad, thanks for the blivet-ui people for the effort to expose an important storage stack. Bye, -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron But it does move! -- Galileo Galilei -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: GNOME 3.13.91 megaupdate
On 09/01/2014 12:40 PM, Kalev Lember wrote: I'm running point on the 3.13.91 builds and will submit it as a single megaupdate in Bodhi later this week. The megaupdate is out now and available in updates-testing. I'd appreciate testing and feedback at https://admin.fedoraproject.org/updates/FEDORA-2014-10210 Thanks, Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20140906 changes
Broken deps for i386 -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.i686 requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.i686 requires libjson.so.0 [aws] aws-devel-3.1.0-6.fc21.i686 requires libgrypt-devel [blender] 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blender-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blender-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blender-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAStreamWriter.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADASaxFrameworkLoader.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADAFramework.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libOpenCOLLADABaseUtils.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libMathMLSolver.so.0.1 1:blenderplayer-2.71-3.fc22.i686 requires libGeneratedSaxParser.so.0.1 [bustle] bustle-0.4.7-2.fc22.i686 requires libHSdbus-0.10.7-ghc7.6.3.so [compat-gcc-34] compat-gcc-34-c++-3.4.6-29.fc19.i686 requires libstdc++ 0:4.9.0 [cp2k] cp2k-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc22.i686 requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc22.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.i686 requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-gcj-compat csound-java-5.19.01-1.fc20.i686 requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.i686 requires libtk8.5.so csound-tk-5.19.01-1.fc20.i686 requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [dnssec-nodes] dnssec-nodes-2.0-5.fc22.i686 requires libval-threads.so.14 dnssec-nodes-2.0-5.fc22.i686 requires libsres.so.14 [dogtag-pki] dogtag-pki-10.2.0-1.fc22.noarch requires pki-ra = 0:10.2.0 [dragonegg] dragonegg-3.4-0.3.rc0.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc22.i686 requires libedelib.so edelib-devel-2.1-5.fc22.i686 requires libedelib.so [elk] elk-openmpi-2.3.22-7.fc21.i686 requires libmpi_usempi.so.1 [elpa] elpa-openmpi-2013.11-4.008.fc21.i686 requires libmpi_usempi.so.1 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.i686 requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc22.i686 requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.i686 requires libftdi.so.1 [flush] flush-0.9.12-10.fc22.i686 requires libtorrent-rasterbar.so.7 [ga] ga-openmpi-5.3b-9.fc21.i686 requires libmpi_usempi.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.i686 requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.i686 requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [gfal2] gfal2-plugin-srm-2.6.8-3.fc22.i686 requires libpugixml.so.1.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.i686 requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [lcg-util] lcg-util-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-libs-1.16.0-3.fc21.i686 requires libgfal.so.1 lcg-util-python-1.16.0-3.fc21.i686 requires libgfal.so.1 [leiningen] leiningen-1.7.1-7.fc20.noarch requires maven-ant-tasks leiningen-1.7.1-7.fc20.noarch requires classworlds [libghemical] libghemical-2.99.1-24.fc20.i686 requires
F-21 Branched report: 20140906 changes
Compose started at Sat Sep 6 07:15:03 UTC 2014 Broken deps for armhfp -- [APLpy] APLpy-0.9.8-5.fc21.noarch requires pywcs [PyKDE] PyKDE-3.16.6-14.fc20.armv7hl requires sip-api(10) = 0:10.0 [PyQuante] PyQuante-libint-1.6.4-11.fc21.1.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [audtty] audtty-0.1.12-9.fc20.armv7hl requires libaudclient.so.2 [authhub] authhub-0.1.2-3.fc19.armv7hl requires libjson.so.0 [couchdb] couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 couchdb-1.6.0-9.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [cp2k] cp2k-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-mpich-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libmpi_usempi.so.1 cp2k-openmpi-2.5.1-8.fc21.armv7hl requires libint(armv7hl-32) = 0:1.1.6-2.fc21 [csound] csound-java-5.19.01-1.fc20.armv7hl requires libgcj_bc.so.1 csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-gcj-compat csound-java-5.19.01-1.fc20.armv7hl requires java-1.5.0-gcj csound-tk-5.19.01-1.fc20.armv7hl requires libtk8.5.so csound-tk-5.19.01-1.fc20.armv7hl requires libtcl8.5.so [deltacloud-core] deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudservers) deltacloud-core-rackspace-1.1.3-1.fc20.noarch requires rubygem(cloudfiles) [docker-registry] docker-registry-0.7.3-1.fc21.noarch requires docker-io [dragonegg] dragonegg-3.4-0.3.rc0.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [edelib] edelib-2.1-5.fc21.armv7hl requires libedelib.so edelib-devel-2.1-5.fc21.armv7hl requires libedelib.so [ejabberd] ejabberd-2.1.13-8.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [erlang-basho_metrics] erlang-basho_metrics-1.0.0-10.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-bitcask] erlang-bitcask-1.6.3-1.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-cl] erlang-cl-1.2.1-2.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-ebloom] erlang-ebloom-1.1.2-4.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-eleveldb] erlang-eleveldb-1.3.2-2.fc20.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-emmap] erlang-emmap-0-0.8.git05ae1bb.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-erlsyslog] erlang-erlsyslog-0.6.2-6.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esasl] erlang-esasl-0.1-15.20120116git665cc80.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-esdl] erlang-esdl-1.3.1-3.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-js] erlang-js-1.2.2-5.fc21.armv7hl requires erlang(erl_drv_version) = 0:2.2 [erlang-sd_notify] erlang-sd_notify-0.1-1.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-skerl] erlang-skerl-1.1.0-7.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [erlang-snappy] erlang-snappy-1.0.3-0.7.git80db168.fc21.armv7hl requires erlang(erl_nif_version) = 0:2.4 [eucalyptus] eucalyptus-common-java-3.3.0-0.5.20130408git32052445.fc20.armv7hl requires hibernate3-jbosscache = 0:3.6.10-7 [fatrat] 1:fatrat-1.2.0-0.21.beta2.fc21.armv7hl requires libtorrent-rasterbar.so.7 [flashrom] flashrom-0.9.6.1-5.svn1705.fc20.armv7hl requires libftdi.so.1 [flush] flush-0.9.12-10.fc21.armv7hl requires libtorrent-rasterbar.so.7 [freesteam] freesteam-ascend-2.1-6.20140724svn753.fc21.armv7hl requires libascend.so.1 [gcc-python-plugin] gcc-python2-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python2-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires libpython3.3dm.so.1.0 gcc-python3-debug-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 gcc-python3-plugin-0.12-18.fc21.armv7hl requires libpython3.3m.so.1.0 gcc-python3-plugin-0.12-18.fc21.armv7hl requires gcc = 0:4.8.2-14.fc21 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [ghc-hint] ghc-hint-devel-0.4.2.0-2.fc21.armv7hl requires ghc-devel(ghc-7.6.3-9662c0f342b2d5c9e1cd2b6330e697bc) [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gnome-shell-extension-pomodoro] gnome-shell-extension-pomodoro-0.10.0-4.fc21.armv7hl requires libupower-glib.so.2 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [hibernate-search]
Re: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 06:35:45PM +0200, Haïkel wrote: 2014-09-05 17:08 GMT+02:00 Pierre-Yves Chibon pin...@pingoured.fr: Dear all, In the last months, Till and I together with infrastructure and release-engineering have been thinking and working on how we could improve the current workflow for new package and new branch. To give you an idea, this is the current workflow: Current new-package procedure: == * packager opens a review-request on bugzilla * reviewer sets the fedora-review flag to ? * reviewer does the review * reviewer sets the fedora-review flag to + * packager creates the scm-request and set fedora-cvs flag to ? * cvsadmin checks the review (check reviewer is a packager, check if reviewee required a sponsor or not, check if there was a review) * cvsadmin processes the scm-request: - Create git repo - Create package in pkgdb * cvsadmin sets fedora-cvs flag to + We thought that a number of these steps could be automated. For example, creating the git repos themselve could be automated using information from pkgdb. Our idea has been to port part of this procedure to pkgdb itself. This is our proposal: overall, kudos for this proposal, it looks better than the current workflow. One question, when do we close the review ticket ? Currently, it is supposed to be handled by the reviewee after the first build but it is often forgotten. Off course, it's the responsability of the reviewer to check this but it's an impediment. Astute people use bodhi to automatically close the ticket when it's build on a branched release, but it's not possible on rawhide. From what I understand, pkgdb2 would be able to link a package to its review, so it should be possible to automatically close the review ticket, am I right ? We can go several ways there: a) let it the way it is now - Closed manualy - Closed via bodhi - Closed after a while when somone goes through his/her list of tickets and see that some can be closed b) let pkgdb close the ticket (once the package is created) c) let pkgdb close the ticket when the only branch requested is rawhide (once the package is created) Obviously, a) requires the less work, b) is easy but c) kind of make more sense as in theory it should be bodhi that closes the ticket (cf a)). New new-branch procedure: = * packager requests new branch in pkgdb (2 clicks) = requests added to the scm admin queue * cvsadmin checks the request/package (check if package exists in the RHEL for EPEL branch request - check if the user is a packager done in pkgdb itself) * cvsadmin approves the creation of the new branch in pkgdb = branch creation broadcasted on fedmsg * git adjusted automatically *nods* Silly question, some of those cvsadmins checks could be automated too, at least, providing hints to the scm admins. Something like a script listening to fedmsg, doing these checks and then sending the results that could be consumed by pkgdb2 (maybe displaying them as flash messages ?) Since the checks will be performed by cvsadmins, manually, I think it make more sense to do them when the admin runs the script rather than automatically based on a fedmsg. Integrated back from fedmsg to pkgdb this type of information might not be easiest thing for no clear advantage, I think. Thanks for the feedbacks and ideas, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Fri, Sep 05, 2014 at 08:12:49PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Sep 05, 2014 at 05:08:39PM +0200, Pierre-Yves Chibon wrote: Dear all, In the last months, Till and I together with infrastructure and release-engineering have been thinking and working on how we could improve the current workflow for new package and new branch. To give you an idea, this is the current workflow: Current new-package procedure: == * packager opens a review-request on bugzilla * reviewer sets the fedora-review flag to ? Is this necessary? Normally having status=ASSIGNED is enough to know that the review is handling the review. One of the issues with current procedure is that this step can be forgotten, and then some automatic steps don't happen when the flag to +. (One that I noticed it that the email with subject 'fedora-review granted' is not sent.) Since you're simplifying the procedure, this manual step could be pruned too. That's a good question, but I don't know how many tools we have that relies on this flag and I suspect there are some. That's a question to bring to releng I guess. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: * packager requests new branch in pkgdb (2 clicks) = requests added to the scm admin queue * cvsadmin checks the request/package (check if package exists in the RHEL for EPEL branch request - check if the user is a packager done in pkgdb itself) I guess, EPEL is just an example for a new branch to create? Indeed, it's just an example. We also have cases were packages only exists in newer Fedoras (eg. rawhide only), until someone comes along and asks for branches to be created in older Fedoras. We would have to clear it with releng, but I wonder what are the mandatory checks to perform when creating a new *fedora* branch for a package that has already been reviewed. If the only check is: is the person a packager?, then I guess we may be able to automatically create the fedora branch in pkgdb (which would then propagate the change to git). * cvsadmin approves the creation of the new branch in pkgdb = branch creation broadcasted on fedmsg * git adjusted automatically What does this sentence mean? Create an empty branch or even to populate it from some other branch? The script creating the git branches has a mapping of which branch to create a new branch from [1]. So new epel7 branches will be created from the f19 branch. I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? Pierre [1] http://infrastructure.fedoraproject.org/infra/ansible/roles/distgit/templates/pkgdb_sync_git_branches.py see BRANCHES_FROM -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 04 Sep 2014 17:34:57 +0200 Miroslav Suchý msu...@redhat.com wrote: Hi, we (the Copr team) would like to allow uploading of source RPM to Copr. It seems that best way is to utilize dist-git [1]. Then Copr will fetch sources and spec file from dist-git and build SRC.RPM the same as Koji does now. And hopefuly you will be able to use fedpkg to interact with Copr. I see two options available: Copr will have its own dist-git instance or we will share dist-git together with Fedora. There are pros and cons for both and I would like to summarize it. 1) Copr will have its own dist-git instance Pros: * no possible conflicts with Fedora * installation of dist-git is tracken in ansible playbook in infra.git, so it should be straightforward (although Pavol Babincak - current maintainer of dist-git - claimed he had hard times to reproduce the installation) Cons: * require additional machine (Fedora currently use 8GB RAM + 2 GB swap and 1 TB of disk) * and additional maintance (although Pavol Babincak claims that there are no problems with running instance, he barely need to touch it) Pavol is one of the maintainers he is not the only one. 2) Copr will share dist-git with Fedora Pros: * no maintenance of new machine * a lot of source are same and shared in look-aside cache (less data stored) * technically easily possible. E.g. for package 'rpm' in Copr project msuchy/foo we can create branch 'msuchy/foo' of dist-git 'rpm'. There are separate ACLs for each branch, so owner of 'msuchy/foo' branch could not affect branch 'f20' and vice versa. Cons: * dist-git use MD5 for checksum [2] therefore it can be practicaly possible to find collision with existing tar.gz and upload new version and Koji will use that file instead. I do not see this as a huge issue * Koji currently build from given SHA of commit of dist git and does not check if it is in correct branch. Therefore it can be theoreticaly possible to submit to Koji build from Copr branch. Afaik you still have to have ACL for that given branch in Fedora, so only Fedora package maintainer can do that and he obviously have no reason for that, but still... technicaly possible. as long as the commit is in git anyone with a koji cert (i.e. potentially anyone who has signed the fpca) can submit a build. until we have ways to make sure builds are from an appropriate branch in koji I will strongly oppose sharing of dist-git * Legal differences - users of Copr does not have to belong to CLA_DONE group. Can it make some problems? I do not know. yes it can, I do not think we should accept contributions from people who have not agreed to the fpca. I do not want to get into a situation where a fedora maintainer pulled commits from a copr repo into Fedora and we are being asked to remove them because they legally could not contribute. Pavol suggested us to have our own instance. But I know there are a lot of people from infra, legal and other team, who can add something insightful before we start working on this. [1] Although I heard one voice saying we should move from home brew code to more standardized git-annex [2] move to SHA is work in progress https://fedorahosted.org/rel-eng/ticket/5846 -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUCyM2AAoJEH7ltONmPFDRHbIP/jxmr3wwWGwqxju1O6XncTac DAPzSSrkUVHvDjdNVt8PCRkVPISGYheKKQubbMems6yC5WpdtncShuv8ww3Yx/+9 WE2ikaAkawi5klPgGkTY1xTBpRV+tmSLXdVd+8A7XS+G9NLpAvhqj+9/AF3F0GHJ mTFZR6jVDE+elNN1DO+fQm88yi21zUie40YPPv8E5yE629PJM4GSwIrA+oqvIBjX YJmXXvOvji9jtGV2hcB8+JVQLKi+n6zJZatRf22CPK9hYCue/AQNzzpMBcYF/nOi WIdncqU10HPFGpJi4RqEfM0mq2Fl0DSP2zfdaD6zzheJCkeDydzUwmc8fD3M8Zcr r0VmZg9l0zl/xwR5dVDlE4agwy1ijoY1PMBMBSIqNe4bUeFX6PxtcWyQk8K5QmQi r1+vrTePo5M5+d7Mw9A4y2hsyuju14VB25JqgGoEpmE4gM0KXTXwaHbISDlEt8g7 AbM8VgiuHERrSvdEMHwLViaqN/07bVMNvsO0IvMS87UDzWWRkuIRuIe4QnJhppE7 aAMOzF5JqweSz6QyVdjTIhIAdjXimakJVCFiTyy5a/8BXMub60UFekXiYmG1/hdO sSlNUnb54e0RtQqPW9/aQl2PxUyfpYy1tDGLF6K1k4TjIijSB6FIduaS2onnI8zm DtJtenHmyz/WxhG1PDUa =GXK3 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
On Sat, Sep 6, 2014 at 5:07 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 04 Sep 2014 17:34:57 +0200 Miroslav Suchý msu...@redhat.com wrote: Hi, we (the Copr team) would like to allow uploading of source RPM to Copr. It seems that best way is to utilize dist-git [1]. Then Copr will fetch sources and spec file from dist-git and build SRC.RPM the same as Koji does now. And hopefuly you will be able to use fedpkg to interact with Copr. I see two options available: Copr will have its own dist-git instance or we will share dist-git together with Fedora. There are pros and cons for both and I would like to summarize it. 1) Copr will have its own dist-git instance Pros: * no possible conflicts with Fedora * installation of dist-git is tracken in ansible playbook in infra.git, so it should be straightforward (although Pavol Babincak - current maintainer of dist-git - claimed he had hard times to reproduce the installation) Cons: * require additional machine (Fedora currently use 8GB RAM + 2 GB swap and 1 TB of disk) * and additional maintance (although Pavol Babincak claims that there are no problems with running instance, he barely need to touch it) Pavol is one of the maintainers he is not the only one. 2) Copr will share dist-git with Fedora Pros: * no maintenance of new machine * a lot of source are same and shared in look-aside cache (less data stored) * technically easily possible. E.g. for package 'rpm' in Copr project msuchy/foo we can create branch 'msuchy/foo' of dist-git 'rpm'. There are separate ACLs for each branch, so owner of 'msuchy/foo' branch could not affect branch 'f20' and vice versa. Cons: * dist-git use MD5 for checksum [2] therefore it can be practicaly possible to find collision with existing tar.gz and upload new version and Koji will use that file instead. I do not see this as a huge issue * Koji currently build from given SHA of commit of dist git and does not check if it is in correct branch. Therefore it can be theoreticaly possible to submit to Koji build from Copr branch. Afaik you still have to have ACL for that given branch in Fedora, so only Fedora package maintainer can do that and he obviously have no reason for that, but still... technicaly possible. as long as the commit is in git anyone with a koji cert (i.e. potentially anyone who has signed the fpca) can submit a build. until we have ways to make sure builds are from an appropriate branch in koji I will strongly oppose sharing of dist-git * Legal differences - users of Copr does not have to belong to CLA_DONE group. Can it make some problems? I do not know. yes it can, I do not think we should accept contributions from people who have not agreed to the fpca. I do not want to get into a situation where a fedora maintainer pulled commits from a copr repo into Fedora and we are being asked to remove them because they legally could not contribute. Huh? What makes one legally not eligible to contribute? Just not signing the fpca? How is that different from someone that submits a patch via bugzilla / mail / whatever? I don't think people check whether those patch submitters have signed the fpca and neither do I think they should. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
Hi On Sat, Sep 6, 2014 at 11:22 AM, drago01 wrote: Huh? What makes one legally not eligible to contribute? Just not signing the fpca? How is that different from someone that submits a patch via bugzilla / mail / whatever? I don't think people check whether those patch submitters have signed the fpca and neither do I think they should. This is a problem that I have with the FPCA and I have highlighted it the advisory board list before and no action was taken. Fedora project members are enforcing it in places where it would be perfectly acceptable to take a patch under an open source license without enforcing the FPCA requirement unnecessarily. There is no legal basis for that. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Fri, 2014-09-05 at 23:47 -0700, Adam Williamson wrote: On Fri, 2014-09-05 at 18:03 +0200, Lennart Poettering wrote: On Fri, 05.09.14 11:52, Matthias Clasen (mcla...@redhat.com) wrote: On Fri, 2014-09-05 at 15:55 +0200, Vratislav Podzimek wrote: On Fri, 2014-09-05 at 09:04 -0400, Bastien Nocera wrote: - Original Message - Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? Actually my question is why not gnome-disk-utility? :) Because it doesn't work well with LVM, RAID, BTRFS and a combination of them. Leaving LVM out was an explicit decision, because of all the system integration problems with LVM. It works fine with RAID and btrfs as far as I know. Do you have any concrete complaints about the RAID or btrfs support in gnome-disk-utility ? Also, note that gnome-disk-utility actually properly separates out the unpriviliged UI from the priviliged backend in udisks. In this day-and-age we should not write new programs anymore that require the entire UI stack to run as root. We should really get away from doing something like that. In the blivet-ui docs su is the recommended way to invoke the program, and that's really wrong for a graphical one. gnome-disk-utility got that right. the new blivet ui did not. And this is not something you can add as an afterthought, you actually need to do your homework and split things up into privileged and non-priviliged parts from the beginning. The blivet-ui thing in this regard is certainly not an improvement over g-d-u, it's a step back. Well...I agree that in perfect theoretical engineering land, it'd be nice if blivet-gui had a better privilege model. I think you're being way too unnecessarily harsh, though, and missing a rather major point. blivet-gui is not 100% new code. The new bit is just the relatively thin GUI wrapper. The really hard code - the bits that do the partitioning - has existed for 15+ years: it's anaconda's partitioning code (lately split out into python-blivet). And that code has *always* assumed it'll run as root, because it's part of an installer that always does. If you want to use the blivet code as the base for a standalone GUI installer and add a better privilege model, that was always going to be a retrofitting job - even if you did it before doing this initial 0.1.x release of blivet-gui, you're still retrofitting. It's really not a significant difference. I can believe it'd be hard work, but I think you overstate the case by a long way when you say it'd be impossible. It may be finicky work, but it seems unlikely that it'd be easier to write an entirely new partitioning app with all of blivet's capabilities from the ground up (with a good privilege model) than it would be to take advantage of all that existing code for doing the very difficult and complex work of partitioning, and retrofit a decent privilege model onto it. well given blivet is a library, shouldn't it be simple enough to put it behind a dbus interface and have the GUI and actual operation be separated by dbus and authorized via mechanisms like polkit or similar ? That should pretty much solve the privilege separation between gui and core code. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
On Sat, Sep 6, 2014 at 5:33 PM, Rahul Sundaram methe...@gmail.com wrote: Hi On Sat, Sep 6, 2014 at 11:22 AM, drago01 wrote: Huh? What makes one legally not eligible to contribute? Just not signing the fpca? How is that different from someone that submits a patch via bugzilla / mail / whatever? I don't think people check whether those patch submitters have signed the fpca and neither do I think they should. This is a problem that I have with the FPCA and I have highlighted it the advisory board list before and no action was taken. Fedora project members are enforcing it in places where it would be perfectly acceptable to take a patch under an open source license without enforcing the FPCA requirement unnecessarily. There is no legal basis for that. Well the FPCA seem to talk about this if someone that didn't sign it sent you a patch all he/she has to do is to provide it under an acceptable license. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Dist-git for Copr
Hi On Sat, Sep 6, 2014 at 12:48 PM, drago01 wrote: Well the FPCA seem to talk about this if someone that didn't sign it sent you a patch all he/she has to do is to provide it under an acceptable license. Yes but we artificially make it seem like FPCA is a requirement even when it isn't https://lists.fedoraproject.org/pipermail/board-discuss/2011-June/010792.html Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Sep 5, 2014 5:05 AM, Vratislav Podzimek vpodz...@redhat.com wrote: Good news, everyone! We (me and CC'd Vojtech Trefny) would like to introduce you the next generation tool for storage management -- the **blivet-gui** tool [1]_. It is a GUI tool based on the blivet python library (originally Anaconda's storage management and configuration tool) inspired by GParted and other storage management tools. Why not use GParted you ask? The reason we came up with blivet-gui is that none of the existing storage management tools supports all storage technologies supported in modern Linux distributions. Anaconda does support them all so it's only logical to take Anaconda's storage backend, combine it with a nice, intuitive and in general user-friendly frontend and build a standalone application for storage management. The GUI of blivet-gui is heavily based on GParted's UI to minimize the surprise which is very important in such a critical task as storage management is. If you know how to work with GParted, you'll almost instantly know how to work with blivet-gui. All requested changes are just enqueued first and then processed/committed to disk by the Apply button just like in GParted. However, with blivet-gui those actions may be something like the following sequence: create 10GB partition sda1, create a LUKS device on top of it and use the LUKS device as a PV for a VG called ``dataVG`` with a single LV ``data`` occupying half of the VG space and with XFS on top of the LV, not only partitioning and file system operations like GParted does. Having troubles writing partitioning part of a kickstart file for automated installation? Run blivet-gui with the ``--kickstart`` option and export the partitioning portion of a kickstart file instead of committing changes to disk. On top of the features described above, the blivet-gui is embedable so any application using any toolkit with the XEmbed protocol support (Gtk, Qt,...) may use blivet-gui as a part of its GUI. The application only started its history few months ago, is under heavy development now and will get new features in the next months (RAID, BTRFS), but even now it is a very nice and useful tool. Suggestions, feature requests, bug reports and of course PATCHES ARE WELCOME! It is quite a simple Gtk application written in Python which makes it an easy target for everybody who misses something in the other storage management tools. Don't like Gtk? Text mode would be really, really useful too! Don't feel like adding new features and diving deep in blivet to implement them? The code always needs refactorization and cleanup! I think everybody can submit patches for blivet-gui and I'm really looking forward to see the hundreds of patches from all those people that hate every storage management GUIs and tools that have every existed. Let's spend some time on pushing the Linux storage management further instead of just complaining! .. [1] http://blog.vojtechtrefny.cz/blivet-gui P.S. Do you know about any other mailing lists or individuals that may be interested in this announcement? Feel free to forward the message and spread the word! This looks excellent, thank you. I look forward to the BTRFS integration, let me know if you have questions on that front. Super excited to see something non-gnome specific. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: blivet-gui announcement
On Sat, 2014-09-06 at 12:47 -0400, Simo Sorce wrote: I can believe it'd be hard work, but I think you overstate the case by a long way when you say it'd be impossible. It may be finicky work, but it seems unlikely that it'd be easier to write an entirely new partitioning app with all of blivet's capabilities from the ground up (with a good privilege model) than it would be to take advantage of all that existing code for doing the very difficult and complex work of partitioning, and retrofit a decent privilege model onto it. well given blivet is a library, shouldn't it be simple enough to put it behind a dbus interface and have the GUI and actual operation be separated by dbus and authorized via mechanisms like polkit or similar ? That should pretty much solve the privilege separation between gui and core code. yeah, that'd be a first step, but presumably the 'ideal' model would distinguish between privileged and non-privileged library operations - mostly, I'd assume, examining current status won't need privs, but making changes will. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Old virt-v2v may be half-retired
I tried to retire the old virt-v2v package: https://admin.fedoraproject.org/pkgdb/package/virt-v2v However I likely only half-retired it because although I'm a package administrator, I'm not the owner, or something like that. In any case I'm coordinating with the package owner and we will have it retired properly by next week. The background here is that virt-v2v and virt-p2v have been rewritten upstream over the past 6 months. The new version is integrated into the libguestfs project. In Fedora virt-v2v will be built as a subpackage of libguestfs = 1.27.39. All of the above applies to Fedora = 21 only, not to any earlier versions, nor to EPEL. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
systemd-readahead
Whenever my laptop boots, the hard disk is pegged at 100% and the machine is unusable for another 2 minutes because of systemd-readahead, a misguided attempt to optimize the boot process. Did we agree to this when we adopted systemd as an init replacement? I don't remember init including all this other stuff. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
Am 06.09.2014 um 23:18 schrieb Richard W.M. Jones: Whenever my laptop boots, the hard disk is pegged at 100% and the machine is unusable for another 2 minutes because of systemd-readahead, a misguided attempt to optimize the boot process. Did we agree to this when we adopted systemd as an init replacement? I don't remember init including all this other stuff for most machines it improves performance it repleaces the seperated readahead service just because it happens between boot / login example: power on machine, get a coffee, login on virtual machines it is conditionally disabled as default ___ if you don't want that or have very slow disks: systemctl mask systemd-readahead-collect.service systemctl mask systemd-readahead-replay.service systemctl mask systemd-readahead-done.timer signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Fri, Sep 05, 2014 at 09:35:10AM +0200, Tomasz Torcz wrote: /tmp has nothing to do with systemd The tmp-on-tmp misfeature is to do with systemd. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Thu, Sep 04, 2014 at 10:31:45AM -0500, Bruno Wolff III wrote: On Thu, Sep 04, 2014 at 16:11:37 +0100, Sérgio Basto ser...@serjux.com wrote: Hi, [1] since Fedora have some responsibility, unfortunately I think the group have some valid reasons , systemd should be the replacement of sysvinit , a built in DHCP !? why ? and others integration like crontab should be modular, for someone else could use his own crontab . OTOH , the support of systemd is not good, we got bug opened and they are ignored as nothing happens, as for example bug https://bugzilla.redhat.com/show_bug.cgi?id=1088619 Boycotting systemd seems like a waste of resources. The various legacy init systems have significant problems and staying with them forever isn't going to happen. If there is a large set of people that don't like the direction systemd is going, they should either be constructively participating in the systemd development process or trying to develop another alternative that fixes the problems with legcay init systems while moving in a direction they do want, if they want to accomplish something. I don't expect anything useful to come out of a boycott. The boycottsystemd website is stupid. However there is a wider problem here. The systemd of Fedora 14/15 is not the systemd of today. We need to decide if just because you manage to get an important core package into Fedora 4 years ago, that means you can forever more push any old stuff you want into Fedora, without going back and consulting with the community and FESCo. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
On Sáb, 2014-09-06 at 22:36 +0100, Richard W.M. Jones wrote: On Thu, Sep 04, 2014 at 10:31:45AM -0500, Bruno Wolff III wrote: On Thu, Sep 04, 2014 at 16:11:37 +0100, Sérgio Basto ser...@serjux.com wrote: Hi, [1] since Fedora have some responsibility, unfortunately I think the group have some valid reasons , systemd should be the replacement of sysvinit , a built in DHCP !? why ? and others integration like crontab should be modular, for someone else could use his own crontab . OTOH , the support of systemd is not good, we got bug opened and they are ignored as nothing happens, as for example bug https://bugzilla.redhat.com/show_bug.cgi?id=1088619 Boycotting systemd seems like a waste of resources. The various legacy init systems have significant problems and staying with them forever isn't going to happen. If there is a large set of people that don't like the direction systemd is going, they should either be constructively participating in the systemd development process or trying to develop another alternative that fixes the problems with legcay init systems while moving in a direction they do want, if they want to accomplish something. I don't expect anything useful to come out of a boycott. The boycottsystemd website is stupid. and completely outdated , gentoo seems that already have systemd and uclibc-systemd also . Although few arguments, seems to me, valid . However there is a wider problem here. The systemd of Fedora 14/15 is not the systemd of today. I agree 100% We need to decide if just because you manage to get an important core package into Fedora 4 years ago, that means you can forever more push any old stuff you want into Fedora, without going back and consulting with the community and FESCo. On Qui, 2014-09-04 at 22:12 +0200, Ralf Corsepius wrote: Therefore I'd find it useful for systemd take a break and period of consolidation to sort out the bugs and impact of systemd on Fedora. yeah this and Chris Adams wrote almost synthesized what I think. what is the systemd goals ? plans ? roadmap ? seems that systemd want to be a operating system. The other problem that folks see when systemd is widely spread on Linux, that is not easy to export to other unix flavors, because the dependencies on kernel and udev which I must agree is not nice, not just for them, but also for us. I understand and agree with logind, localed etc, the sysconfig in systemd and all what is about init scripts, but some other features are more difficult to understand, we must think on Linux to be in embedded systems to super-computer systems ... -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
Hi On Sat, Sep 6, 2014 at 5:36 PM, Richard W.M. Jones wrote: We need to decide if just because you manage to get an important core package into Fedora 4 years ago, that means you can forever more push any old stuff you want into Fedora, without going back and consulting with the community and FESCo. I am puzzled. Upstream doesn't need to consult FESCo for developing new features. However it does need to consult FESCo for Fedora integration and it seems that systemd has. Can you point out any counter examples? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: New Group Calls For Boycotting Systemd
HI On Sat, Sep 6, 2014 at 5:30 PM, Richard W.M. Jones wrote: On Fri, Sep 05, 2014 at 09:35:10AM +0200, Tomasz Torcz wrote: /tmp has nothing to do with systemd The tmp-on-tmp misfeature is to do with systemd. How? systemd works fine without it. Many distributions have switched to systemd without having tmp-on-tmps. You could file a FESCo ticket asking for it to be reverted if you have feel strongly about it (and I know you do) Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
On 09/06/2014 02:18 PM, Richard W.M. Jones wrote: Whenever my laptop boots, the hard disk is pegged at 100% and the machine is unusable for another 2 minutes because of systemd-readahead, a misguided attempt to optimize the boot process. Did we agree to this when we adopted systemd as an init replacement? I don't remember init including all this other stuff. Then has been a readahead service in Red Hat distros for as long as I can remember. It seems to have a beneficial effect to me, but I've never tried benchmarking it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Future changes in the new package and new branch processes
On 09/06/2014 03:09 PM, Pierre-Yves Chibon wrote: On Sat, Sep 06, 2014 at 07:52:52AM +0200, Ralf Corsepius wrote: On 09/05/2014 05:08 PM, Pierre-Yves Chibon wrote: * cvsadmin approves the creation of the new branch in pkgdb = branch creation broadcasted on fedmsg * git adjusted automatically What does this sentence mean? Create an empty branch or even to populate it from some other branch? The script creating the git branches has a mapping of which branch to create a new branch from [1]. So new epel7 branches will be created from the f19 branch. I wonder if we should rather create an empty branch and let the packager merge the branch of his/her interest back into this new branch. Thoughts? I think the only safe way is to create an empty branch and not to populate it, because there are many constraints to be considered before a package can be added to an older branch. E.g. a package may have a chain of dependencies, which can't be fullfilled because something else is missing on this older release and can't be upgraded to a compatible version. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: systemd-readahead
On Sat, Sep 06, 2014 at 10:18:20PM +0100, Richard W.M. Jones wrote: Whenever my laptop boots, the hard disk is pegged at 100% and the machine is unusable for another 2 minutes because of systemd-readahead, a misguided attempt to optimize the boot process. Did we agree to this when we adopted systemd as an init replacement? It was part of original feature: https://fedoraproject.org/wiki/Features/systemd Nb. readhead was removed from upstream systemd recently. Fedora can either follow upstream and drop it, or patch back in. And you can disable it on your system any time. I don't remember init including all this other stuff. systemd suite is collection of utilities and APIs for building Linux systemd. It contains init among other things. Changing init was most discussed thing, but let's not pretend systemd == init only. -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Samba as AD DC
Hi, Is (Samba) Fedora 20 still not capable of being Active Directory Domain Controller? I mean is that page current: http://fedoraproject.org/wiki/Features/Samba4#Current_status ? Thanks in advance! -- -- Sergio Belkin http://www.sergiobelkin.com LPIC-2 Certified - http://www.lpi.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Nonresponsive maintainer: Takanori Matsuura
Takanori Matsuura (fas: tmatssu) cant be reached for a long time. There are no reply on email, in bugreport [1], there are no koji builds [2], even more, from the previous message, Jiro Matsuzawa tell he contact him personaly (a week ago) nut there were no actions. At all mentioned above, I request orphaning Takanori Matsuura's packages: NearTree [3] and CVector [4]. Dmitrij. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1105916 [2] http://koji.fedoraproject.org/koji/userinfo?userID=1247 [3] https://admin.fedoraproject.org/pkgdb/package/NearTree/ [4] https://admin.fedoraproject.org/pkgdb/package/CVector/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1138910] New: perl-App-cpanminus-1.7006 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1138910 Bug ID: 1138910 Summary: perl-App-cpanminus-1.7006 is available Product: Fedora Version: rawhide Component: perl-App-cpanminus Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 1.7006 Current version/release in Fedora Rawhide: 1.7004-2.fc21 URL: http://search.cpan.org/dist/App-cpanminus/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=qJSbj2VEPba=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Dumbbench
perl-Dumbbench has broken dependencies in the rawhide tree: On armhfp: perl-Dumbbench-BoxPlot-0.09-1.fc22.noarch requires perl(SOOT) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1138947] New: perl-CGI-Fast-2.03 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1138947 Bug ID: 1138947 Summary: perl-CGI-Fast-2.03 is available Product: Fedora Version: rawhide Component: perl-CGI-Fast Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Latest upstream release: 2.03 Current version/release in Fedora Rawhide: 2.02-1.fc21 URL: http://search.cpan.org/dist/CGI-Fast/ 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 Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/ It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=I2NrThOnwJa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Mock-Quick-1.108.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Mock-Quick: 12905859f36b8eead78cd989bae51fd7 Mock-Quick-1.108.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-Mock-Quick] Update to 1.108
commit cdcc7492618fc4d5b47d23eba00fc9f1c8ec7d50
Author: Paul Howarth p...@city-fan.org
Date: Sat Sep 6 19:35:44 2014 +0100
Update to 1.108
- New upstream release 1.108
- Fix some warnings
- Fix some typos
perl-Mock-Quick.spec | 16 +++-
sources |2 +-
2 files changed, 12 insertions(+), 6 deletions(-)
---
diff --git a/perl-Mock-Quick.spec b/perl-Mock-Quick.spec
index 391b85f..3f46245 100644
--- a/perl-Mock-Quick.spec
+++ b/perl-Mock-Quick.spec
@@ -1,6 +1,6 @@
Name: perl-Mock-Quick
-Version: 1.107
-Release: 4%{?dist}
+Version: 1.108
+Release: 1%{?dist}
Summary: Quickly mock objects and classes, side-effect free
License: GPL+ or Artistic
Group: Development/Libraries
@@ -8,7 +8,8 @@ URL:https://metacpan.org/release/Mock-Quick
Source0:
http://cpan.metacpan.org/authors/id/E/EX/EXODIST/Mock-Quick-%{version}.tar.gz
BuildArch: noarch
# Module Build
-BuildRequires: perl(Module::Build) = 0.40
+BuildRequires: perl
+BuildRequires: perl(Module::Build) = 0.42
# Module Runtime
BuildRequires: perl(base)
BuildRequires: perl(Carp)
@@ -48,11 +49,11 @@ control object falls out of scope, the original class is
restored.
%setup -q -n Mock-Quick-%{version}
%build
-perl Build.PL installdirs=vendor
+perl Build.PL --installdirs=vendor
./Build
%install
-./Build install destdir=%{buildroot} create_packlist=0
+./Build install --destdir=%{buildroot} --create_packlist=0
%{_fixperms} %{buildroot}
%check
@@ -71,6 +72,11 @@ perl Build.PL installdirs=vendor
%{_mandir}/man3/Object::Quick.3pm*
%changelog
+* Sat Sep 6 2014 Paul Howarth p...@city-fan.org - 1.108-1
+- Update to 1.108
+ - Fix some warnings
+ - Fix some typos
+
* Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 1.107-4
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 09c96aa..d8279c0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-74e12065780203466245adc44c8eac93 Mock-Quick-1.107.tar.gz
+12905859f36b8eead78cd989bae51fd7 Mock-Quick-1.108.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-Mock-Quick] Created tag perl-Mock-Quick-1.108-1.fc22
The lightweight tag 'perl-Mock-Quick-1.108-1.fc22' was created pointing to: cdcc749... Update to 1.108 -- 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 Crypt-Random-Source-0.10.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Crypt-Random-Source: 80303278c2851f5114ee22417db0b935 Crypt-Random-Source-0.10.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-Crypt-Random-Source] Update to 0.10
commit b4405a4029e4a78618ef48fb81cfc076da47723b
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 22:12:54 2014 +0200
Update to 0.10
.gitignore|1 +
perl-Crypt-Random-Source.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6e2c4d8..349bcaf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Crypt-Random-Source-0.07.tar.gz
/Crypt-Random-Source-0.08.tar.gz
/Crypt-Random-Source-0.09.tar.gz
+/Crypt-Random-Source-0.10.tar.gz
diff --git a/perl-Crypt-Random-Source.spec b/perl-Crypt-Random-Source.spec
index 7085ba1..b6001db 100644
--- a/perl-Crypt-Random-Source.spec
+++ b/perl-Crypt-Random-Source.spec
@@ -1,6 +1,6 @@
Name: perl-Crypt-Random-Source
-Version:0.09
-Release:2%{?dist}
+Version:0.10
+Release:1%{?dist}
Summary:Get weak or strong random data from pluggable sources
License:GPL+ or Artistic
@@ -54,6 +54,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 0.10-1
+- Update to 0.10
+
* Mon Sep 01 2014 Jitka Plesnikova jples...@redhat.com - 0.09-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 587a08f..a6023c0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-d900da829b95fd35d535423b2a8c736f Crypt-Random-Source-0.09.tar.gz
+80303278c2851f5114ee22417db0b935 Crypt-Random-Source-0.10.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 Hijk-0.17.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Hijk: 7c01dba0449d33246c64c5a2a0c0c4bf Hijk-0.17.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-Hijk] Update to 0.17
commit 0900fa6bdb55e19ad1f7e118696022ea1acdd2b1
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 22:20:36 2014 +0200
Update to 0.17
.gitignore |1 +
perl-Hijk.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ace2c8d..7f548c9 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Hijk-0.12.tar.gz
/Hijk-0.13.tar.gz
/Hijk-0.16.tar.gz
+/Hijk-0.17.tar.gz
diff --git a/perl-Hijk.spec b/perl-Hijk.spec
index a8881dd..51e4704 100644
--- a/perl-Hijk.spec
+++ b/perl-Hijk.spec
@@ -1,6 +1,6 @@
Name: perl-Hijk
-Version:0.16
-Release:2%{?dist}
+Version:0.17
+Release:1%{?dist}
Summary:Specialized HTTP client
License:MIT
@@ -64,6 +64,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 0.17-1
+- Update to 0.17
+
* Mon Sep 01 2014 Jitka Plesnikova jples...@redhat.com - 0.16-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 01c415c..174c1ee 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-366e2215de77c59c6efd680bdc596970 Hijk-0.16.tar.gz
+7c01dba0449d33246c64c5a2a0c0c4bf Hijk-0.17.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 Mojolicious-5.38.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Mojolicious: 100f2071b9acd260f5789efcdbf46769 Mojolicious-5.38.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-Mojolicious] Update to 5.38
commit 4137f5fb945de0a60d7e261ae8e1614a647f0f0d
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 22:25:55 2014 +0200
Update to 5.38
.gitignore|1 +
perl-Mojolicious.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3b3812e..e0b9391 100644
--- a/.gitignore
+++ b/.gitignore
@@ -139,3 +139,4 @@ Mojolicious-0.26.tar.gz
/Mojolicious-5.24.tar.gz
/Mojolicious-5.29.tar.gz
/Mojolicious-5.35.tar.gz
+/Mojolicious-5.38.tar.gz
diff --git a/perl-Mojolicious.spec b/perl-Mojolicious.spec
index f517645..81ca2e9 100644
--- a/perl-Mojolicious.spec
+++ b/perl-Mojolicious.spec
@@ -1,6 +1,6 @@
Name: perl-Mojolicious
-Version:5.35
-Release:2%{?dist}
+Version:5.38
+Release:1%{?dist}
Summary:A next generation web framework for Perl
License:Artistic 2.0
@@ -61,6 +61,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 5.38-1
+- Update to 5.38
+
* Wed Sep 03 2014 Jitka Plesnikova jples...@redhat.com - 5.35-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 825171e..4a7740f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-f349ba44f6c854941b9d6bce9dacb0d0 Mojolicious-5.35.tar.gz
+100f2071b9acd260f5789efcdbf46769 Mojolicious-5.38.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 Test-Routine-0.020.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Test-Routine: 62a15cc01d21d4f02266efad92fae303 Test-Routine-0.020.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 1138351] epel7 branch
https://bugzilla.redhat.com/show_bug.cgi?id=1138351 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org --- perl-File-Tail-0.99.3-21.el7 has been pushed to the Fedora EPEL 7 testing repository. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=XBtZcP9Li5a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Routine] Update to 0.020
commit fba0a104430fa71fed2d3de2bb5bb9acd0c75fb4
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 22:35:13 2014 +0200
Update to 0.020
.gitignore |1 +
perl-Test-Routine.spec |7 +--
sources|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 62ba5cd..1d775b0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Test-Routine-0.015.tar.gz
/Test-Routine-0.019.tar.gz
+/Test-Routine-0.020.tar.gz
diff --git a/perl-Test-Routine.spec b/perl-Test-Routine.spec
index 0c0980e..471c466 100644
--- a/perl-Test-Routine.spec
+++ b/perl-Test-Routine.spec
@@ -1,7 +1,7 @@
Name: perl-Test-Routine
Summary:Composable units of assertion
-Version:0.019
-Release:2%{?dist}
+Version:0.020
+Release:1%{?dist}
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Test-Routine/
Source0:
http://www.cpan.org/authors/id/R/RJ/RJBS/Test-Routine-%{version}.tar.gz
@@ -70,6 +70,9 @@ make test
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 0.020-1
+- Update to 0.020
+
* Mon Sep 01 2014 Jitka Plesnikova jples...@redhat.com - 0.019-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 04c6caf..212b43d 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3110657c07f2ac68646aa6e614fa284d Test-Routine-0.019.tar.gz
+62a15cc01d21d4f02266efad92fae303 Test-Routine-0.020.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 Unicode-Stringprep-1.105.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Unicode-Stringprep: bf9ffbc387cc12d67a3875be1cd8e105 Unicode-Stringprep-1.105.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-Unicode-Stringprep] Update to 1.105
commit a4f2cd52e647779defabae8902545af913d576e9
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 22:54:53 2014 +0200
Update to 1.105
.gitignore |1 +
perl-Unicode-Stringprep.spec | 11 ---
sources |2 +-
3 files changed, 10 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 40b22bf..b7752ec 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
/Unicode-Stringprep-1.104.tar.gz
+/Unicode-Stringprep-1.105.tar.gz
diff --git a/perl-Unicode-Stringprep.spec b/perl-Unicode-Stringprep.spec
index c864e3e..62687e2 100644
--- a/perl-Unicode-Stringprep.spec
+++ b/perl-Unicode-Stringprep.spec
@@ -1,7 +1,7 @@
Name: perl-Unicode-Stringprep
Summary:Preparation of Internationalized Strings (RFC 3454)
-Version:1.104
-Release:7%{?dist}
+Version:1.105
+Release:1%{?dist}
License:GPL+ or Artistic
URL:http://search.cpan.org/dist/Unicode-Stringprep/
Source0:
http://www.cpan.org/authors/id/C/CF/CFAERBER/Unicode-Stringprep-%{version}.tar.gz
@@ -54,12 +54,17 @@ mv README.utf8 README
%files
-%doc Changes eg LICENSE README
+%doc Changes eg README
+%license LICENSE
%{perl_vendorlib}/Unicode
%{_mandir}/man3/Unicode::Stringprep*3pm*
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 1.105-1
+- Update to 1.105
+- Use the %%license macro
+
* Wed Aug 27 2014 Jitka Plesnikova jples...@redhat.com - 1.104-7
- Perl 5.20 rebuild
diff --git a/sources b/sources
index a961094..2cbaf08 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-cd19b39c9d3dd7caf6db4b2bf3464a72 Unicode-Stringprep-1.104.tar.gz
+bf9ffbc387cc12d67a3875be1cd8e105 Unicode-Stringprep-1.105.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 EV-4.18.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-EV: 5931d0ba91f93b95723e80d573da606f EV-4.18.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-EV] Update to 4.18
commit 5933f0d54a93079961cbf4337109b02da41c4328
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 23:05:55 2014 +0200
Update to 4.18
.gitignore |1 +
perl-EV.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 243a4a9..f226c58 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
/EV-4.03.tar.gz
/EV-4.11.tar.gz
/EV-4.17.tar.gz
+/EV-4.18.tar.gz
diff --git a/perl-EV.spec b/perl-EV.spec
index aac12e7..1571eb0 100644
--- a/perl-EV.spec
+++ b/perl-EV.spec
@@ -1,6 +1,6 @@
Name: perl-EV
-Version:4.17
-Release:3%{?dist}
+Version:4.18
+Release:1%{?dist}
Summary:Wrapper for the libev high-performance event loop library
# Note: The source archive includes a libev/ folder which contents are licensed
@@ -72,6 +72,9 @@ make test
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 4.18-1
+- Update to 4.18
+
* Wed Sep 03 2014 Jitka Plesnikova jples...@redhat.com - 4.17-3
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 6f3eabc..15c851f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ffc39299fab4589bb850b5a46ccd2395 EV-4.17.tar.gz
+5931d0ba91f93b95723e80d573da606f EV-4.18.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 Net-FTPSSL-0.25.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-Net-FTPSSL: 77bffaffd20a1c2452d66ea1824b475e Net-FTPSSL-0.25.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-Net-FTPSSL] Update to 0.25
commit 346ce3720326c5fa06885758e2220eadd5b2f6a9
Author: Emmanuel Seyman emman...@seyman.fr
Date: Sat Sep 6 23:11:43 2014 +0200
Update to 0.25
.gitignore |1 +
perl-Net-FTPSSL.spec |7 +--
sources |2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index c33015a..d54295d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@ Net-FTPSSL-0.15.tar.gz
/Net-FTPSSL-0.22.tar.gz
/Net-FTPSSL-0.23.tar.gz
/Net-FTPSSL-0.24.tar.gz
+/Net-FTPSSL-0.25.tar.gz
diff --git a/perl-Net-FTPSSL.spec b/perl-Net-FTPSSL.spec
index 42c6dc1..a569e88 100644
--- a/perl-Net-FTPSSL.spec
+++ b/perl-Net-FTPSSL.spec
@@ -1,6 +1,6 @@
Name: perl-Net-FTPSSL
-Version:0.24
-Release:2%{?dist}
+Version:0.25
+Release:1%{?dist}
Summary:Perl module for FTP over SSL/TLS
License:GPL+ or Artistic
Group: Development/Libraries
@@ -57,6 +57,9 @@ echo n |make test
%changelog
+* Sat Sep 06 2014 Emmanuel Seyman emman...@seyman.fr - 0.25-1
+- Update to 0.25
+
* Thu Aug 28 2014 Jitka Plesnikova jples...@redhat.com - 0.24-2
- Perl 5.20 rebuild
diff --git a/sources b/sources
index 392baf0..fcd77db 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-5642ade84d3009ae1db4cc69faab3c0b Net-FTPSSL-0.24.tar.gz
+77bffaffd20a1c2452d66ea1824b475e Net-FTPSSL-0.25.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
glibc issue while build in epel
Hello there, I'm facing an issue while making arch-specific scratch builds in EPEL branches. They fail during test stage while they build just fine on my own machine(s) with the same arch. Build log: --- t/clone...ok t/digest..*** glibc detected *** /usr/bin/perl: corrupted double-linked list: 0x00d4afa0 *** === Backtrace: = /lib64/libc.so.6[0x7f83973cc283] /lib64/libc.so.6(__libc_malloc+0x6e)[0x7f83973cddfe] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_safesysmalloc+0x3b)[0x7f839863801b] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_gv_init+0x8d)[0x7f83985f945d] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_gv_fetchmeth+0xaa)[0x7f83985f9b0a] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_gv_fetchmeth_autoload+0x91)[0x7f83985fbb81] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_Gv_AMupdate+0x1f9)[0x7f83985fbe09] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_gv_handler+0x5c)[0x7f83985fc0dc] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sv_clear+0x13d)[0x7f839865346d] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sv_free+0x80)[0x7f8398653b50] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_gp_free+0xad)[0x7f83985f8ead] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sv_clear+0x561)[0x7f8398653891] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sv_free+0x80)[0x7f8398653b50] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so[0x7f83986510c5] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(Perl_sv_clean_objs+0x3a)[0x7f839865113a] /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so(perl_destruct+0x11be)[0x7f83985f785e] /usr/bin/perl(main+0xb3)[0x401773] /lib64/libc.so.6(__libc_start_main+0xf4)[0x7f83973779f4] /usr/bin/perl[0x401609] ... and so on. --- More details here: https://kojipkgs.fedoraproject.org//work/tasks/8985/7538985/build.log Failed builds: https://koji.fedoraproject.org/koji/taskinfo?taskID=7538983 (EPEL 5) https://koji.fedoraproject.org/koji/taskinfo?taskID=7538987 (EPEL 6) https://koji.fedoraproject.org/koji/taskinfo?taskID=7538976 (EPEL 7) Is it a temporary bug there? -- wbr, Denis. -- 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 1138971] Review Request: perl-Data-Faker - Perl extension for generating fake data
https://bugzilla.redhat.com/show_bug.cgi?id=1138971 Denis Fateyev de...@fateyev.com changed: What|Removed |Added CC||perl-devel@lists.fedoraproj ||ect.org -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kgsyOR0VOAa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Devel
perl-Catalyst-Devel has broken dependencies in the epel-6 tree: On ppc64: perl-Catalyst-Devel-1.28-1.el6.1.noarch requires perl(File::Copy::Recursive) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the epel-6 tree: On x86_64: perl-OpenOffice-UNO-0.07-4.el6.x86_64 requires libsal_textenc.so.3()(64bit) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Catalyst-Devel
perl-Catalyst-Devel has broken dependencies in the epel-6 tree: On ppc64: perl-Catalyst-Devel-1.28-1.el6.1.noarch requires perl(File::Copy::Recursive) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-OpenOffice-UNO
perl-OpenOffice-UNO has broken dependencies in the epel-6 tree: On x86_64: perl-OpenOffice-UNO-0.07-4.el6.x86_64 requires libsal_textenc.so.3()(64bit) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 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
