EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 895 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 227 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 114 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 15 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2655/python-oauth2-1.5.211-7.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2750/libsrtp-1.4.4-10.20101004cvs.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2719/nodejs-0.10.32-1.el6,v8-3.14.5.10-14.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2742/TeXmacs-1.0.7.2-3.el6 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2713/putty-0.63-3.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2850/nginx-1.0.15-7.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2811/nodejs-qs-0.6.6-3.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2821/nodejs-send-0.3.0-4.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2801/seamonkey-2.21-8.ESR_24.8.0.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2981/check-mk-1.2.4p5-2.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3024/rssh-2.3.4-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3080/phpMyAdmin-4.0.10.4-1.el6 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3082/golang-1.3.3-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing Lmod-5.7.5-1.el6 game-music-emu-0.6.0-5.el6 hercules-3.11-1.el6 python-fedmsg-meta-fedora-infrastructure-0.3.3-1.el6 x2goserver-4.0.1.17-1.el6 Details about builds: Lmod-5.7.5-1.el6 (FEDORA-EPEL-2014-3125) Environmental Modules System in Lua Update Information: Update to 5.7.5. There are several bug fixes and some better explantation to the user when there is a bad collection that must be rebuilt and some other small things. The big new feature that is available in 5.7.5 is the ability to group the output of avail into blocks with labels other than the directory name. game-music-emu-0.6.0-5.el6 (FEDORA-EPEL-2014-3131) Video game music file emulation/playback library Update Information: update to latest stable ChangeLog: * Sat Aug 16 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.6.0-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.6.0-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild * Fri Sep 20 2013 Karel Volný kvo...@redhat.com 0.6.0-3 - Adjust virtual provides according to further comments on bug#1006881 * Fri Sep 13 2013 Karel Volný kvo...@redhat.com 0.6.0-2 - Add virtual provides libgme (bug #1006881) * Thu Aug 22 2013 Karel Volný kvo...@redhat.com 0.6.0-1 - New release - See changes.txt for list of upstream changes - Adds pkgconfig file (+ patch to correct path) * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.5.5-5 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Wed Feb 13 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.5.5-4 - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild * Thu Jul 19 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.5.5-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.5.5-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild hercules-3.11-1.el6 (FEDORA-EPEL-2014-3116) Hercules S/370, ESA/390, and z/Architecture emulator Update Information: updated to 3.11 - Floating-Point-Extension Facility (Roger Bowler) - Enhanced Channel-to-Channel Adapter via TCP/IP (Peter J. Jansen) - Load/Store-on-Condition Facility corrections (Neale Ferguson) - LCS corrections (Paul Gorlinsky, David Fish Trout, Ivan Warren) - Floating-Point-Extension Facility corrections (Neale Ferguson) - CMPSC corrections (Bernard van der Helm) - Load sequential datasets from XMIT
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 895 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 350 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 114 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 57 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2150/drupal7-7.31-1.el5 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2424/389-ds-base-1.2.11.32-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2669/check-mk-1.2.4p5-1.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2694/TeXmacs-1.0.7.2-3.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2686/putty-0.63-3.el5 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2728/phpMyAdmin4-4.0.10.3-2.el5 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2853/mediawiki119-1.19.18-1.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2895/libvncserver-0.9.10-0.6.20140718git9453be42.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3041/rssh-2.3.4-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3114/mksh-50c-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing mksh-50c-1.el5 Details about builds: mksh-50c-1.el5 (FEDORA-EPEL-2014-3114) MirBSD enhanced version of the Korn Shell Update Information: R50c is a security fix release: * Know more rare signals when generating sys_signame[] replacement * OpenBSD sync (mostly RCSID only) * Document HISTSIZE limit; found by luigi_345 on IRC * Fix link to Debian .mkshrc * Cease exporting $RANDOM (Debian #760857) * Fix C99 compatibility * Work around klibc bug causing a coredump (Debian #763842) * Use issetugid(2) as additional check if we are FPRIVILEGED * SECURITY: do not permit += from environment * Fix more field splitting bugs reported by Stephane Chazelas and mikeserv; document current status wrt. ambiguous ones as testcases too ChangeLog: * Fri Oct 3 2014 Robert Scheck rob...@fedoraproject.org 50c-1 - Upgrade to 50c ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 15 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2657/python-oauth2-1.5.211-7.el7 10 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2748/nodejs-0.10.32-1.el7,v8-3.14.5.10-14.el7 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2825/nginx-1.6.2-1.el7 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2861/nodejs-qs-0.6.6-3.el7 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2870/nodejs-send-0.3.0-4.el7 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2992/check-mk-1.2.4p5-2.el7 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3070/phpMyAdmin-4.2.9.1-1.el7 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-3062/golang-1.3.3-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing Lmod-5.7.5-1.el7 eigen3-3.2.2-1.el7 hercules-3.11-1.el7 libdc1394-2.2.2-3.el7 nodejs-filed-0.1.0-2.el7 paraview-4.2.0-1.el7 perl-Variable-Magic-0.54-2.el7 python-apipkg-1.2-6.el7 python-cpuinfo-0.1.2-2.el7 python-fedmsg-meta-fedora-infrastructure-0.3.3-1.el7 python-hgdistver-0.21-2.el7 tipcutils-2.0.6-1.el7 x2goserver-4.0.1.17-1.el7 Details about builds: Lmod-5.7.5-1.el7 (FEDORA-EPEL-2014-3120) Environmental Modules System in Lua Update Information: Update to 5.7.5. There are several bug fixes and some better explantation to the user when there is a bad collection that must be rebuilt and some other small things. The big new feature that is available in 5.7.5 is the ability to group the output of avail into blocks with labels other than the directory name. ChangeLog: * Fri Sep 5 2014 Orion Poplawski or...@cora.nwra.com - 5.7.5-1 - Update to 5.7.5 eigen3-3.2.2-1.el7 (FEDORA-EPEL-2014-3124) A lightweight C++ template library for vector and matrix math Update Information: Update to release 3.2.2, see http://eigen.tuxfamily.org/index.php?title=ChangeLog#Eigen_3.2.2 for details. ChangeLog: * Mon Aug 4 2014 Sandro Mani manisan...@gmail.com - 3.2.2-1 - Update to release 3.2.2 hercules-3.11-1.el7 (FEDORA-EPEL-2014-3126) Hercules S/370, ESA/390, and z/Architecture emulator Update Information: updated to 3.11 - Floating-Point-Extension Facility (Roger Bowler) - Enhanced Channel-to-Channel Adapter via TCP/IP (Peter J. Jansen) - Load/Store-on-Condition Facility corrections (Neale Ferguson) - LCS corrections (Paul Gorlinsky, David Fish Trout, Ivan Warren) - Floating-Point-Extension Facility corrections (Neale Ferguson) - CMPSC corrections (Bernard van der Helm) - Load sequential datasets from XMIT files (Roger Bowler) - Eliminate compiler warnings for Linux and Mac (Roger Bowler) ChangeLog: * Mon Sep 29 2014 Dan Horák dan[at]danny.cz - 3.11-1 - updated to 3.11 (#1142927) * Sat Aug 16 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 3.10-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 3.10-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild References: [ 1 ] Bug #1142927 - hercules-3.11 is available https://bugzilla.redhat.com/show_bug.cgi?id=1142927 libdc1394-2.2.2-3.el7 (FEDORA-EPEL-2014-3129) 1394-based digital camera control library Update Information: libdc1394 for EPEL7 References: [ 1 ] Bug #1123223 - Please Branch libdc1394 for EPEL7 https://bugzilla.redhat.com/show_bug.cgi?id=1123223
Re: How to handle upgrades to Fedora 21
On Sat, Oct 4, 2014 at 1:27 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Oct 03, 2014 at 06:18:11PM -0500, Michael Catanzaro wrote: I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. But vanilla is the most delicious. But has no meaning that context for pretty much all non english languages. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-21 Branched report: 20141004 changes
Compose started at Sat Oct 4 07:15:02 UTC 2014 Broken deps for armhfp -- [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 [avro] avro-mapred-1.7.5-9.fc21.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc21.noarch requires hadoop-client [cduce] cduce-0.5.5-9.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [check-mk] check-mk-agent-1.2.4p5-1.fc21.armv7hl requires /usr/bin/ksh check-mk-multisite-1.2.4p5-1.fc21.noarch requires /usr/bin/ksh [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 [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) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [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 [elpa] elpa-openmpi-2013.11-4.008.fc21.armv7hl requires libmpi_usempi.so.1 [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 [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 [gdb-heap] gdb-heap-0.5-18.fc21.armv7hl requires glibc(armv7hl-32) = 0:2.19.90 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.armv7hl requires libvala-0.24.so.0 [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.armv7hl requires libmetacity-private.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) = 0:0.16.0 [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.armv7hl requires libf77blas.so.3 libghemical-2.99.1-24.fc20.armv7hl requires libatlas.so.3 [libopensync-plugin-irmc] 1:libopensync-plugin-irmc-0.22-7.fc20.armv7hl requires libopenobex.so.1 [ltsp] ltsp-client-5.4.5-8.fc21.armv7hl requires fuse-unionfs ltsp-server-5.4.5-8.fc21.armv7hl requires cdialog [meshmagick] meshmagick-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 meshmagick-libs-0.6.0-20.svn2898.fc21.armv7hl requires libOgreMain.so.1.8.1 [monodevelop-vala] monodevelop-vala-2.8.8.1-6.fc21.armv7hl requires vala 0:0.25.0 [netdisco] netdisco-1.1-7.fc21.noarch requires perl(SNMP::Info::Layer2::Bay) [ocaml-pa-do] ocaml-pa-do-0.8.16-3.fc21.armv7hl requires ocaml(Camlp4) = 0:ebd368022fd2bc7b305a42902efa4c90 [openslides] openslides-1.3.1-3.fc21.noarch requires python-django 0:1.5 [openstack-nova] openstack-nova-compute-2014.1.2-1.fc21.noarch requires libvirt-daemon-xen [openvas-client] openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_omp.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_nasl.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_misc.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_hg.so.6 openvas-client-3.0.3-8.fc20.armv7hl requires libopenvas_base.so.6 [perl-RT-Authen-ExternalAuth] perl-RT-Authen-ExternalAuth-0.11-5.fc21.noarch requires rt3 [perl-RT-Extension-CommandByMail] perl-RT-Extension-CommandByMail-0.07-10.fc21.noarch requires perl(RT::Interface::Email) [pipelight-selinux] pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight-common pipelight-selinux-0.2.1-2.fc21.noarch requires pipelight
Review Swap : dnfdaemon - Dbus daemon for dnf package actions
If someone would review this one and let me know what to review Review Request: dnfdaemon - Dbus daemon for dnf package actions https://bugzilla.redhat.com/show_bug.cgi?id=1149390 Tim -- 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: 20141004 changes
Compose started at Sat Oct 4 05:15:08 UTC 2014 Broken deps for i386 -- [Agda] ghc-Agda-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-Agda-devel-2.3.2.2-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [PyQuante] PyQuante-libint-1.6.4-11.fc22.1.i686 requires libint(x86-32) = 0:1.1.6-2.fc21 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [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 [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [darcs] darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-2.8.4-5.fc22.i686 requires libHSterminfo-0.3.2.5-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires libHShaskeline-0.7.0.3-ghc7.6.3.so ghc-darcs-2.8.4-5.fc22.i686 requires ghc(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-2.8.4-5.fc22.i686 requires ghc(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(terminfo-0.3.2.5-61e0dc43a1465e327dacd9ab37bbe1a3) ghc-darcs-devel-2.8.4-5.fc22.i686 requires ghc-devel(haskeline-0.7.0.3-775b029f16a4b58f3cc6b4cb4f7e7ac5) [debconf] debconf-1.5.53-1.fc22.noarch requires perl(:MODULE_COMPAT_5.18.2) [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) [django-recaptcha] django-recaptcha-0.1-7.20091212svn6.fc21.noarch requires python-django14 [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 [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 [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 [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 [gedit-valencia] gedit-valencia-0.4.0-1.20131223git94442bf.fc21.i686 requires libvala-0.24.so.0 [ghc-hjsmin] ghc-hjsmin-0.1.4.7-3.fc22.i686 requires libHSoptparse-applicative-0.9.0-ghc7.6.3.so [gnome-python2-desktop] gnome-python2-metacity-2.32.0-18.fc21.i686 requires libmetacity-private.so.0 [gobby05] gobby05-0.4.94-8.fc22.i686 requires libinftextgtk-0.5.so.0 gobby05-0.4.94-8.fc22.i686 requires libinftext-0.5.so.0 gobby05-0.4.94-8.fc22.i686 requires libinfinity-0.5.so.0 gobby05-0.4.94-8.fc22.i686 requires libinfgtk-0.5.so.0 [gofer] ruby-gofer-0.77.1-2.fc21.noarch requires rubygem(qpid) =
Re: How to handle upgrades to Fedora 21
On 10/03/2014 07:37 PM, Ray Strode wrote: Hi, I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant and i'll just throw another out there now 5) fedora-release-respin If we do want to change it, it should happen soon --Ray To me, nonstandard has more meaning that standard and diy or noncompliant are meaningless. However, custom can be understood and has a meaning: the user has specifically tailored the package set for this system. Just saying ... Gene -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
dnf vs yum
I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* because I forget and use yum instead of dnf in rawhide. I am not really needing anything special, just install a package, or run dnf update to update rawhide. Thanks, Paulo -- 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: dnf vs yum
I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* there is no need to do so because I forget and use yum instead of dnf in rawhide. I am not really needing anything special, just install a package, or run dnf update to update rawhide but why do you think you need to touch anything below /var/lib/rpm/? that's the rpm database you should never touch without damned good reasons like follow dist-upgrade instructions you can happily use yum and dnf on the same setup all the time and the warnings rpm database modified or similar are harmless, you may even trigger them by touch the rpmdb by hand 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: How to handle upgrades to Fedora 21
On Fri, 2014-10-03 at 19:37 -0400, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard That this was the first item on the list suggests that fedora-release-standard is not the right name. :) In fact, most of the names on your list are antonyms of standard. 3) fedora-release-diy Not a good name for spins. This sounds like Gentoo. 4) fedora-release-noncompliant This one makes it sound like not running a product is a bad thing. Let's avoid this one. All the other names are fine. I still like fedora-release-generic the best. My favorite color of paint is Myrtle Green. It's a nice color. [1] Michael [1] https://en.wikipedia.org/wiki/Shades_of_green#Myrtle_green signature.asc Description: This is a digitally signed message part -- 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: dnf vs yum
2014-10-04 11:08 GMT-03:00 Reindl Harald h.rei...@thelounge.net: First think of me of as just an slightly above average user :) I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* there is no need to do so I switched to using dnf because yum stopped working at some point. I think it was something related to a libdb-5 update when only dnf would work. because I forget and use yum instead of dnf in rawhide. I am not really needing anything special, just install a package, or run dnf update to update rawhide but why do you think you need to touch anything below /var/lib/rpm/? that's the rpm database you should never touch without damned good reasons like follow dist-upgrade instructions I learned to do that (rm -f /var/lib/rpm/__db*) long long ago, as the standard way to recover from minor rpm database corruption. But I survived extreme cases where not even rpm --rebuilddb would work. As long as the Packages database is not (completely) corrupted, it should be possible to recover... you can happily use yum and dnf on the same setup all the time and the warnings rpm database modified or similar are harmless, you may even trigger them by touch the rpmdb by hand It does not work for me... I sent the email because, I again, forgot and run $ sudo yum update and gone to another terminal, a bit later I learned that yum thought all updates would be duplicates, so I did $ sudo rm -f /var/lib/rpm/__db* $ sudo dn update sent the email, and now, update to latest rawhide has already finished... Thanks, Paulo -- 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: dnf vs yum
Am 04.10.2014 um 16:49 2014-10-04 11:08 GMT-03:00 Reindl Harald h.rei...@thelounge.net: First think of me of as just an slightly above average user :) I am sorry I did not fully follow the discussions earlier. I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* there is no need to do so I switched to using dnf because yum stopped working at some point. I think it was something related to a libdb-5 update when only dnf would work. but than you have a different problem not really related to the subject because I forget and use yum instead of dnf in rawhide. I am not really needing anything special, just install a package, or run dnf update to update rawhide but why do you think you need to touch anything below /var/lib/rpm/? that's the rpm database you should never touch without damned good reasons like follow dist-upgrade instructions I learned to do that (rm -f /var/lib/rpm/__db*) long long ago, as the standard way to recover from minor rpm database corruption. But I survived extreme cases where not even rpm --rebuilddb would work. As long as the Packages database is not (completely) corrupted, it should be possible to recover... as said: than you have a much deeper problem you can happily use yum and dnf on the same setup all the time and the warnings rpm database modified or similar are harmless, you may even trigger them by touch the rpmdb by hand It does not work for me... I sent the email because, I again, forgot and run $ sudo yum update and gone to another terminal, a bit later I learned that yum thought all updates would be duplicates, so I did $ sudo rm -f /var/lib/rpm/__db* $ sudo dn update sent the email, and now, update to latest rawhide has already finished... again: something is broken on your system and you should fix that with the help of package-cleanup and options like dupes, prohans and so on what you see is not normal and don't match the subject both, yum and dnf are *frontends* for the rpm database which is a complete different layer hence you can use plain rpm -Uvh, yum and dnf as you like if it don't come to dependencies where dnf/yum are still frontends for rpm and just do the work you would normally need to do by hand 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: Dash as default shell
On 10/04/2014 01:05 AM, Rahul Sundaram wrote: On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote: And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or CentOS or Scientific Linux, pretty seriously Please explain how. Systems which haven't undergone UsrMove don't have /usr/bin/bash. -- Florian Weimer / Red Hat Product Security -- 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: Dash as default shell
Dne 4.10.2014 v 18:00 Florian Weimer napsal(a): On 10/04/2014 01:05 AM, Rahul Sundaram wrote: On Fri, Oct 3, 2014 at 6:59 PM, Nico Kadel-Garci wrote: And it's going to break backports to EPEL for RHEL 5 or RHEL 6, or CentOS or Scientific Linux, pretty seriously Please explain how. Systems which haven't undergone UsrMove don't have /usr/bin/bash. We still have universal: #/usr/bin/env bash Zdenek -- 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: How to handle upgrades to Fedora 21
Reindl Harald writes: Am 03.10.2014 um 23:57 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote: generic is technical speak or for normal people outside IT at best has a negative context to generica and spam I never heared about „generica” and seing the term „generic” I don't have any associations with spam. - standard for the ordinary user means not specialized so likely the best decision for me Exactly the message Fedora doesn't want to send to its users. Thanks for confirming +1 why? not specialized means i can likely do anything i want with that and is true it is the exactly right message for any user which has no clue what the products may mean for him or if he is unsure which one is the best - so in doubt just use standard and later install whatever you need as all the years before is the correct decision why would you try to force somebody to a prodcut setup if he can't give you an answer to the question which? From my understanding and impression the approach Fedora had so far is exactly opposite to what you are describing now. The „standard” and „default” was a full desktop with Gnome. And the „install minimal whatever, and decide later what to do” has always been a „custom” / „minimal” installation. Calling it now „standard” is indeed confusing. Especially for user which has no clue. „Standard” should be something *well* defined. Not a „whatever” configuration different for each user. Personally I don't care, but thinking about newcomers and less experienced users, I'd strongly vote for changing the name „standard” to something different if it is not too late. -- jaroslav pgprEHhouj6Fu.pgp Description: 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: Dash as default shell
On 10/04/2014 06:03 PM, Zdenek Kabelac wrote: We still have universal: #/usr/bin/env bash Sadly, some systems have /bin/env, but not /usr/bin/env. -- Florian Weimer / Red Hat Product Security -- 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: Dash as default shell
Am 04.10.2014 um 18:08 schrieb Florian Weimer: On 10/04/2014 06:03 PM, Zdenek Kabelac wrote: We still have universal: #/usr/bin/env bash Sadly, some systems have /bin/env, but not /usr/bin/env on the Fedoras side a non-brainer just use /bin/env since after UsrMove both works 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: How to handle upgrades to Fedora 21
Am 04.10.2014 um 18:08 schrieb Jaroslav Nahorny: Am 03.10.2014 um 23:57 schrieb Rahul Sundaram: On Fri, Oct 3, 2014 at 5:38 PM, Reindl Harald wrote: generic is technical speak or for normal people outside IT at best has a negative context to generica and spam I never heared about „generica” and seing the term „generic” I don't have any associations with spam https://www.google.com/search?q=spam+generic+viagra there is even a SpamAssassin tag DRUG_ED_GENERIC 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: Dash as default shell
Dne 4.10.2014 v 18:08 Florian Weimer napsal(a): On 10/04/2014 06:03 PM, Zdenek Kabelac wrote: We still have universal: #/usr/bin/env bash Sadly, some systems have /bin/env, but not /usr/bin/env. Sadly it's fault of that distro - Fedora is not here to fix other distro mistakes... 'env' is usr tool and needs to sit in /usr/bin - it's simple as that. In fact it should be used also to resolve pythons and other goodies... And yes - with UsrMove we lost distinction between what are system tools and what are usr tools. Zdenek -- 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: dnf vs yum
On Sat, Oct 04, 2014 at 11:02:23AM -0300, Paulo César Pereira de Andrade wrote: I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* because I forget and use yum instead of dnf in rawhide. I'm not sure why you would need to do that because of running yum, but, one thing you can do is remove the yum package and install dnf-yum instead, which provides a /usr/bin/yum compatibility wrapper. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: How to handle upgrades to Fedora 21
On Sat, Oct 04, 2014 at 11:56:41AM +0200, drago01 wrote: I agree with Rahul that standard is not a great name for the nonstandard, non-productized upgrade, though. Generic is more descriptive anyway. But vanilla is the most delicious. But has no meaning that context for pretty much all non english languages. True, but it's a very well established idiom in English, and it's worth noting that for trademark reasons we won't be translating any of the Cloud, Server, Workstation names, either. Anyway, it's just the color of paint _I_ would choose. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: How to handle upgrades to Fedora 21
On 3 Oct 2014, at 19:37, Ray Strode wrote: I'm not sure it's worth repainting the bikeshed at this point, but during the alluded-to discussion a few alternative names came up that would have been better than fedora-release-standard: 1) fedora-release-nonstandard 2) fedora-release-custom 3) fedora-release-diy 4) fedora-release-noncompliant The nonstandard and noncompliant names seem a bit pejorative. However, fedora-release-custom and fedora-release-diy (do-it- yourself) and fedora-release-pyop (pick-your-own-packageset) and fedora-release-byob (bring-your-own-blueprint) all have similar meanings to this US-English speaker, and all seem like reasonable choices, although the last three might require a parenthetical explanation for some folk. Yes, Myrtle Green would make a nice color for the bike shed. -- Mike Pinkerton -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
fedora-review: 'Illegal return' warnings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. These warnings appear during a package review; apparently, fedora-review command completes all its tasks. WARNING: Illegal return from /usr/share/fedora-review/scripts/generic-excludearch.sh, code 82, output: stdout:None stderr:./review-env.sh: line 7: unset: `BASH_FUNC_module()': not a valid identifier WARNING: Illegal return from /usr/share/fedora-review/scripts/generic-large-docs.sh, code 82, output: stdout:Documentation size is 30720 bytes in 3 files. stderr:./review-env.sh: line 7: unset: `BASH_FUNC_module()': not a valid identifier WARNING: Illegal return from /usr/share/fedora-review/scripts/generic-srv-opt.sh, code 80, output: stdout:None stderr:./review-env.sh: line 7: unset: `BASH_FUNC_module()': not a valid identifier WARNING: Illegal return from /usr/share/fedora-review/scripts/generic-large-data.sh, code 80, output: stdout:None stderr:./review-env.sh: line 7: unset: `BASH_FUNC_module()': not a valid identifier What they are? - -- Antonio Trande mailto: sagitterATfedoraproject.org http://fedoraos.wordpress.com/ https://fedoraproject.org/wiki/User:Sagitter GPG Key: 0x66E15D00 Check on https://keys.fedoraproject.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUMDh/AAoJEFyovWBm4V0ATB4P/ituuJrGN4qRIZsrrRU3y/w/ 51hiYUB+68XmfDfdun3PO3EEJMZkm1KfZ7cSqOhAfziUFhviYlkS4T43pSE+2fRT WjC4vRsfXSlsRNnTSBikV7iUZjCPqSHsINNucHiMkUJtumfDoN48RqhwgCqqes2V PaHiV0JTsC30hicle8xrMdAQeVchvTODz4wpiUNUJAKfQY0Ha5VisymRB1At1G+5 13xSVvbsUCqUW389jg2NAXzoHKcONfQIO0Do+ud6KSfKpP1yNWsiKZlb/ML166iw aVDnA1BRR5e5EPPYKJ19z4G+GJ+DxBMMvhVAFFw2qOXheJa+XMrFASBWGBN0cCKA 0ApgSo6QAMDDnmvTCLGbEZSLv/ETaAvBpKOchAJQIeMtY8agxr0D5v6GOyh/IgC4 QSZNfVmnn7A1m2iNZLX+fDXraf5LX88qODdDcTcy2u6ZcZDvO/I+l5QXuQKvNPeg 6dtaylrQ/BmQHJrpJfZXeefUjBFZQCr+A8wxsddEIV8DVBb2oTI4B9qtO95xbAO7 uzSM2tpwsH2g9iRElmNzbFXMtOquVojAfiFt5JqTieyo68NmM2psf65k5ZdICVIC huY3FsbCyv+HqJWekOp7TipiRcl8+dh8SlTntdsxW16PhpwNMidA3a01TvhYE6g2 ATA7fKMvYrmmeJUzNCdT =fR6X -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: fedora-review: 'Illegal return' warnings
On 2014-10-04 20:12, Antonio Trande wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all. These warnings appear during a package review; apparently, fedora-review command completes all its tasks. WARNING: Illegal return from /usr/share/fedora-review/scripts/generic-excludearch.sh, code 82, output: stdout:None stderr:./review-env.sh: line 7: unset: `BASH_FUNC_module()': not a valid identifier Hm seems that recent bash patch to fix the shellshock problem introduces this. Fedora-review relies on exported shell functions (export -f) and the bash fix changes the syntax for exported functions in an incompatible way. For now, this means that you should check these things manually: - Nothing under /srv, /opt or /usr/local - Package (or it's dependencies) is not known to require an ExcludeArch tag. - Large data in /usr/share should live in a noarch subpackage. - Large (or many) docs must go in a -doc subpackage. Besides this, you can safely ignore these errors. For fedora-review we need to evaluate what is reqiured to stay compatible with bash after this Shellshock issue. Cheers! --alec -- 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: dnf vs yum
2014-10-04 13:32 GMT-03:00 Matthew Miller mat...@fedoraproject.org: On Sat, Oct 04, 2014 at 11:02:23AM -0300, Paulo César Pereira de Andrade wrote: I only recall it was supposed to exist some compatibility layer at some point. But I keep all the time needing to $ sudo rm -f /var/lib/rpm/__db* because I forget and use yum instead of dnf in rawhide. I'm not sure why you would need to do that because of running yum, but, one thing you can do is remove the yum package and install dnf-yum instead, which provides a /usr/bin/yum compatibility wrapper. Sorry for late reply. I was aware of dnf-yum, that I assume will magically correct my problem. I did not remove plain yum so far on purpose, because I was expecting it to be automatically replaced, or kept working, but only now I sent a note about the problems I noticed :) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader Thanks, Paulo -- 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: dnf vs yum
Hi On Sat, Oct 4, 2014 at 5:03 PM, Paulo César Pereira de Andrade I did not remove plain yum so far on purpose, because I was expecting it to be automatically replaced, or kept working, but only now I sent a note about the problems I noticed :) Would you filing a bug report against yum or dnf? I use both interchangeability (for testing dnf) and I haven't run into this issue. https://fedoraproject.org/wiki/How_to_file_a_bug_report http://bugz.fedoraproject.org/dnf 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: dnf vs yum
2014-10-04 18:23 GMT-03:00 Rahul Sundaram methe...@gmail.com: Hi On Sat, Oct 4, 2014 at 5:03 PM, Paulo César Pereira de Andrade I did not remove plain yum so far on purpose, because I was expecting it to be automatically replaced, or kept working, but only now I sent a note about the problems I noticed :) Would you filing a bug report against yum or dnf? I use both interchangeability (for testing dnf) and I haven't run into this issue. I checked that I was talking from experience as 1 or more weeks ago. For a single package install indeed, dnf and yum are now working. I figured I have a lot of duplicates left from some earlier update, for example: $ rpm -q xz-libs xz-libs-5.1.2-13alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.i686 So, I should work on some script to rpm -e --justdb the older ones. The initial report in this thread was due to another kind of error, e.g. yum update says among thousands of other lines: xz-libs-5.1.2-15alpha.fc22.i686 is a duplicate with xz-libs-5.1.2-13alpha.fc22.x86_64 but yum output could be good as input for some script attempting to fix my rawhide, example: 4:texlive-zxjafbfont-svn28539.0-2.fc22.noarch is a duplicate with 4:texlive-zxjafbfont-svn28539.0-1.fc22.noarch 4:texlive-zxjafont-svn30105.0.2-2.fc22.noarch is a duplicate with 4:texlive-zxjafont-svn30105.0.2-1.fc22.noarch 4:texlive-zxjatype-svn28541.0.6-2.fc22.noarch is a duplicate with 4:texlive-zxjatype-svn28541.0.6-1.fc22.noarch Just to have an idea: $ sudo yum update /tmp/yum $ wc -l /tmp/yum 3589 /tmp/yum $ sudo dnf update /tmp/dnf $ wc -l /tmp/dnf 2 /tmp/dnf $ cat /tmp/dnf Dependencies resolved. Nothing to do. https://fedoraproject.org/wiki/How_to_file_a_bug_report http://bugz.fedoraproject.org/dnf If I manage to make a clean bug report I will submit it. Rawhide changes too fast that when one takes some time, and fills a bug report, it may have been already fixed :) Rahul Thanks, Paulo -- 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: dnf vs yum
I checked that I was talking from experience as 1 or more weeks ago. For a single package install indeed, dnf and yum are now working. I figured I have a lot of duplicates left from some earlier update, for example: $ rpm -q xz-libs xz-libs-5.1.2-13alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.x86_64 xz-libs-5.1.2-15alpha.fc22.i686 So, I should work on some script to rpm -e --justdb the older ones as i already said - just stop to mangle around in your rpmdb and use the tools available for years * yum install yum-utils * package-cleanup --help * package-cleanup --dupes * package-cleanup --cleandupes the subject is stil wrong as well as the mailing list you have a *local* problem 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
Review needed for new StarCluster version
I need python-sphinxcontrib-issuetracker to update to the latest version of StarCluster. Any help appreciated: https://bugzilla.redhat.com/show_bug.cgi?id=1089416 I could probably review something in return as well :) -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- 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: btrfs as default filesystem for F22?
I'm happy with ext4. Just out of curiosity, though, how is XFS working out on RHEL 7? On Fri, Oct 3, 2014 at 6:43 PM, Ian Kent ra...@themaw.net wrote: On Fri, 2014-10-03 at 13:18 +0200, Juan Orti Alcaine wrote: El 2014-10-03 11:38, Steven Whitehouse escribió: Hi, I should also add (just in case anybody gets the wrong idea!) that I think it should definitely be made as easy as possible for anybody who wants to evaluate running btrfs on Fedora, but it is far too early to make it the default yet, I agree with your opinion, it's a bit too early. An experienced user can deal with the idiosyncrasies of btrfs and it's great when you learn it, but pushing it as the default seems too adventurous. I want to add to the list of problems the performance degradation over time in database-like files (journal, vm images, firefox and other sqlite db). I have experienced minutes of delay consulting the journal in heavily fragmented journal files. I still have to agree with not making btrfs the default. Sadly, I see BUG(), ENOSPC error reports (seem to have returned), and btrfs-progs SEGV reports on the btrfs mailing quite regularly and while much of the functionality may now be stable all the features of the default file system will get stressed more than the other file systems, including the perhaps not so stable ones. -- Juan Orti https://miceliux.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Twitter: http://twitter.com/znmeb; Computational Journalism on a Stick http://j.mp/CompJournoStickOverview Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Qt
perl-Qt has broken dependencies in the rawhide tree: On x86_64: perl-Qt-0.96.0-11.fc22.x86_64 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.x86_64 requires libperl.so.5.18()(64bit) On i386: perl-Qt-0.96.0-11.fc22.i686 requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.i686 requires libperl.so.5.18 On armhfp: perl-Qt-0.96.0-11.fc22.armv7hl requires perl(:MODULE_COMPAT_5.18.2) perl-Qt-0.96.0-11.fc22.armv7hl requires libperl.so.5.18 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 1141390] Review Request: perl-DBIx-RunSQL - Run SQL commands from a file
https://bugzilla.redhat.com/show_bug.cgi?id=1141390 --- Comment #2 from Denis Fateyev de...@fateyev.com --- I skipped Pod::Readme and Pod::Markdown dependencies intentionally because they didn't affect the build or core functionality, - and the first was missing in epel7 [1], the second was missing both in el5 and el6 [2]. $ rpmlint perl-DBIx-RunSQL-0.12-1.fc22.src.rpm perl-DBIx-RunSQL-0.12-1.fc22.noarch.rpm perl-DBIx-RunSQL.noarch: W: wrong-file-end-of-line-encoding /usr/share/doc/perl-DBIx-RunSQL/README 2 packages and 0 specfiles checked; 0 errors, 1 warnings. I think they can be omitted but if it's important I can either add a conditional for el5,el6 or exclude them from build entirely (actually, I wouldn't do that.) [1] http://pkgs.fedoraproject.org/cgit/perl-Pod-Readme.git I've recently posted the update: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-2808/perl-Pod-Readme-0.110-11.el7 but it hasn't reached stable repo yet. [2] http://pkgs.fedoraproject.org/cgit/perl-Pod-Markdown.git -- 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=KnamfVOj5Ca=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-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-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-XML-Xerces
perl-XML-Xerces has broken dependencies in the epel-5 tree: On ppc: perl-XML-Xerces-2.7.0_0-4.el5.ppc requires libxerces-c.so.27 On x86_64: perl-XML-Xerces-2.7.0_0-4.el5.x86_64 requires libxerces-c.so.27()(64bit) On i386: perl-XML-Xerces-2.7.0_0-4.el5.i386 requires libxerces-c.so.27 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-Getopt-GUI-Long
perl-Getopt-GUI-Long has broken dependencies in the epel-5 tree: On ppc: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On x86_64: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On i386: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) 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-QWizard
perl-QWizard has broken dependencies in the epel-5 tree: On ppc: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On x86_64: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On i386: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) 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-QWizard
perl-QWizard has broken dependencies in the epel-5 tree: On ppc: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On x86_64: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On i386: perl-QWizard-3.15-8.el5.noarch requires perl(Gtk2) On ppc: perl-QWizard-3.15-9.el5.noarch requires perl(Gtk2) On x86_64: perl-QWizard-3.15-9.el5.noarch requires perl(Gtk2) On i386: perl-QWizard-3.15-9.el5.noarch requires perl(Gtk2) 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-Getopt-GUI-Long
perl-Getopt-GUI-Long has broken dependencies in the epel-5 tree: On ppc: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On x86_64: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) On i386: perl-Getopt-GUI-Long-0.91-5.el5.noarch requires perl(Gtk2) 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 1141390] Review Request: perl-DBIx-RunSQL - Run SQL commands from a file
https://bugzilla.redhat.com/show_bug.cgi?id=1141390 --- Comment #3 from David Dick dd...@cpan.org --- Those modules are required in Makefile.PL, so BuildRequires should be put in place for them. Having Pod::Readme available allows the regeneration of the README file, which fixes the end-of-line issue noted by rpmlint. I think that BR can be added without causing you to miss out on anything? Pod-Markdown can be skipped as the resulting README.mkdn is not included in the RPM (correctly, as it is an exact copy of the README file) Is that ok? -- 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=5sMtZw0hQEa=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
