EPEL epel beta report: 20140322 changes
Compose started at Sat Mar 22 08:15:03 UTC 2014 Broken deps for x86_64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires mod_python chemtool-1.6.14-1.el7.x86_64 requires openbabel chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires python-glanceclient docker-registry-0.6.5-1.el7.noarch requires python-backports-lzma globus-gram-job-manager-pbs-1.6-7.el7.x86_64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.x86_64 requires gridengine koji-vm-1.8.0-2.el7.noarch requires python-virtinst lxc-templates-0.9.0-3.el7.x86_64 requires dpkg lxc-templates-0.9.0-3.el7.x86_64 requires debootstrap lxc-templates-0.9.0-3.el7.x86_64 requires busybox mate-desktop-1.8.0-2.el7.x86_64 requires mate-panel mate-desktop-1.8.0-2.el7.x86_64 requires mate-control-center-filesystem mate-screensaver-1.8.0-1.el7.x86_64 requires mate-keyring-pam mate-settings-daemon-1.8.0-1.el7.x86_64 requires mate-control-center-filesystem mate-themes-1.8.1-0.1.git20140304.5a900ef.el7.noarch requires gtk2-engines mate-themes-1.8.1-0.1.git20140304.5a900ef.el7.noarch requires gtk-murrine-engine mcollective-common-2.4.1-1.el7.noarch requires rubygem(systemu) mcollective-common-2.4.1-1.el7.noarch requires rubygem(stomp) nf3d-0.8-2.el7.noarch requires python-visual openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg php-phpseclib-crypt-aes-0.3.5-2.el7.noarch requires php-pear(phpseclib.sourceforge.net/Crypt_Rijndael) = 0:0.3.0 plowshare-0.9.4-0.46.20140112git.el7.noarch requires caca-utils python-tgcaptcha2-0.2.0-5.el7.noarch requires python-fedora-turbogears qt4pas-2.5-3.el7.x86_64 requires fpc-src rabbitvcs-core-0.16-1.el7.noarch requires python-dulwich rabbitvcs-core-0.16-1.el7.noarch requires pysvn rabbitvcs-nautilus-0.16-1.el7.x86_64 requires nautilus-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunarx-python rabbitvcs-thunar-0.16-1.el7.x86_64 requires thunar rubygem-gssapi-1.1.2-3.el7.noarch requires rubygem(ffi) = 0:1.0.1 rubygem-mizuho-0.9.20-2.el7.noarch requires rubygem(sqlite3) rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-mocks) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-expectations) = 0:2.14.1 rubygem-rspec-2.14.1-1.el7.noarch requires rubygem(rspec-core) = 0:2.14.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(simplecov-html) = 0:0.7.1 rubygem-simplecov-0.7.1-8.el7.noarch requires rubygem(multi_json) = 0:1.0 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) 0:1 rubygem-term-ansicolor-1.2.2-3.el7.noarch requires rubygem(tins) = 0:0.8 spectrwm-2.5.0-1.el7.x86_64 requires xlockmore spectrwm-2.5.0-1.el7.x86_64 requires dmenu Broken deps for ppc64 -- 2ping-2.0-2.el7.noarch requires perl(Digest::CRC) RemoteBox-1.7-1.el7.noarch requires rdesktop RemoteBox-1.7-1.el7.noarch requires perl-Gtk2 bodhi-server-0.9.8-2.el7.noarch requires python-simplemediawiki bodhi-server-0.9.8-2.el7.noarch requires python-fedora-turbogears 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires mod_python chemtool-1.6.14-1.el7.ppc64 requires openbabel chm2pdf-0.9.1-13.el7.noarch requires python-chm chm2pdf-0.9.1-13.el7.noarch requires htmldoc cloud-init-0.7.2-8.el7.noarch requires python-requests cloud-init-0.7.2-8.el7.noarch requires dmidecode docker-registry-0.6.5-1.el7.noarch requires redis docker-registry-0.6.5-1.el7.noarch requires python-rsa docker-registry-0.6.5-1.el7.noarch requires python-requests docker-registry-0.6.5-1.el7.noarch requires python-redis docker-registry-0.6.5-1.el7.noarch requires python-keystoneclient docker-registry-0.6.5-1.el7.noarch requires
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 700 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 190 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 154 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 129 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 119 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 34 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0837/lighttpd-1.4.35-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0834/389-ds-base-1.2.11.28-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0840/mediawiki119-1.19.13-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0918/php-pecl-Fileinfo-1.0.4-3.el5,php-pecl-zip-1.8.10-3.el5,php-extras-5.1.6-6.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing duply-1.7.0-1.el5 python26-boto-2.27.0-1.el5 root-5.34.18-1.el5 salt-2014.1.1-1.el5 Details about builds: duply-1.7.0-1.el5 (FEDORA-EPEL-2014-0931) Wrapper for duplicity Update Information: Update to the latest released version. Changes in version 1.7.0: - disabled gpg key id plausibility check, too many valid possibilities - featreq 7 Halt if precondition fails: added and(+), or(-) batch command(separator) support - featreq 26 pre/post script with shebang line: if a script is flagged executable it's executed in a subshell now as opposed to sourced to bash, which is the default - bugfix: do not check if dpbx, swift credentials are set anymore - bugfix: properly escape profile name, archdir if used as arguments - add DUPL_PRECMD conf setting for use with e.g. trickle ChangeLog: * Fri Mar 21 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.7.0-1 - Update to 1.7.0. python26-boto-2.27.0-1.el5 (FEDORA-EPEL-2014-0929) A simple, lightweight interface to Amazon Web Services Update Information: Among other things, this update fixes breakage in the Eucalyptus-specific get_all_vmtypes method by replacing it with a functional get_all_instance_types method upstream. For more details of the changes between version 2.25.0-2 and this version, see the upstream release notes: http://docs.pythonboto.org/en/latest/releasenotes/v2.26.0.html http://docs.pythonboto.org/en/latest/releasenotes/v2.27.0.html ChangeLog: * Fri Mar 21 2014 Garrett Holmstrom gho...@fedoraproject.org - 2.27.0-1 - Updated to 2.27.0 References: [ 1 ] Bug #1079523 - Please update to boto 2.27.0 or newer https://bugzilla.redhat.com/show_bug.cgi?id=1079523 root-5.34.18-1.el5 (FEDORA-EPEL-2014-0928) Numerical data analysis framework Update Information: Update to 5.34.18 http://root.cern.ch/drupal/content/root-version-v5-34-00-patch-release-notes ChangeLog: * Sat Mar 22 2014 Mattias Ellert mattias.ell...@fysast.uu.se - 5.34.18-1 - Update to 5.34.18 - Build GFAL module using libgfal2 - New sub-package: root-vdt salt-2014.1.1-1.el5 (FEDORA-EPEL-2014-0925) A parallel remote execution system Update Information: Update to bugfix release 2014.1.1 ChangeLog: * Fri Mar 21 2014 Erik Johnson e...@saltstack.com - 2014.1.1-1 - Update to bugfix release 2014.1.1 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 700 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 129 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 47 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 42 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6 31 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0845/asterisk-1.8.26.1-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0846/mediawiki119-1.19.13-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0852/lighttpd-1.4.35-1.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0888/v8-3.14.5.10-7.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0889/moodle-2.4.9-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing NetworkManager-openvpn-0.8.1-0.2.git20100609.el6 duply-1.7.0-1.el6 nodejs-ansi-styles-1.0.0-1.el6 nodejs-chalk-0.4.0-1.el6 nodejs-concat-stream-1.4.4-2.el6 nodejs-grunt-contrib-clean-0.5.0-1.el6 nodejs-grunt-contrib-internal-0.4.8-1.el6 nodejs-has-color-0.1.4-1.el6 nodejs-pretty-bytes-0.1.0-1.el6 nodejs-strip-ansi-0.1.1-1.el6 perl-Image-SubImageFind-0.03-1.el6 perl-Net-Twitter-Lite-0.12006-1.el6 perl-X11-GUITest-0.28-1.el6 python-boto-2.27.0-1.el6 root-5.34.18-1.el6 salt-2014.1.1-1.el6 Details about builds: NetworkManager-openvpn-0.8.1-0.2.git20100609.el6 (FEDORA-EPEL-2014-0934) NetworkManager VPN plugin for OpenVPN Update Information: - Backported upstream patch to support keysize option (#471397) - Removed import/export workaround patch that causes build failures ChangeLog: * Thu Mar 21 2013 Robert Scheck rob...@fedoraproject.org - 1:0.8.1-0.2.git20100609 - Backported upstream patch to support keysize option (#471397) - Removed import/export workaround patch that causes build failures References: [ 1 ] Bug #471397 - nm-openvpn[15690]: Authenticate/Decrypt packet error: cipher final failed https://bugzilla.redhat.com/show_bug.cgi?id=471397 duply-1.7.0-1.el6 (FEDORA-EPEL-2014-0933) Wrapper for duplicity Update Information: Update to the latest released version. Changes in version 1.7.0: - disabled gpg key id plausibility check, too many valid possibilities - featreq 7 Halt if precondition fails: added and(+), or(-) batch command(separator) support - featreq 26 pre/post script with shebang line: if a script is flagged executable it's executed in a subshell now as opposed to sourced to bash, which is the default - bugfix: do not check if dpbx, swift credentials are set anymore - bugfix: properly escape profile name, archdir if used as arguments - add DUPL_PRECMD conf setting for use with e.g. trickle ChangeLog: * Fri Mar 21 2014 Thomas Moschny thomas.mosc...@gmx.de - 1.7.0-1 - Update to 1.7.0. nodejs-ansi-styles-1.0.0-1.el6 (FEDORA-EPEL-2014-0932) ANSI escape codes for colorizing strings in the terminal Update Information: Initial package. nodejs-chalk-0.4.0-1.el6 (FEDORA-EPEL-2014-0932) Terminal string styling done right Update Information: Initial package. nodejs-concat-stream-1.4.4-2.el6 (FEDORA-EPEL-2014-0932) Writable stream that concatenates data and calls a callback with the result Update Information: Initial package.
Re: Maybe it's time to get rid of tcpwrappers/tcpd?
Am 22.03.2014 03:07, schrieb Lennart Poettering: On Fri, 21.03.14 23:46, Reindl Harald (h.rei...@thelounge.net) wrote: if you believe it or not: there exists code which don't neeed updates and reweites all te time because it just works and given You do realize that if software engineering has shown something then yes, software development is never finished, it's a process. You do need maintains for such things i do not need maintains for things just working you do because it's your passion to replace, change and deprecate many others and i need working systems to do my work on them 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: Maybe it's time to get rid of tcpwrappers/tcpd?
Am 22.03.2014 03:05, schrieb Lennart Poettering: On Fri, 21.03.14 23:35, Reindl Harald (h.rei...@thelounge.net) wrote: In other words you are telling us that now to get something implemented or removed in Fedora we have to not only deal with our usual politics and bureaucracy but also all the downstream distribution to us as well... no, in other words he told you that whe world is not turning around a few people deperecating anything which does not get a update for the sake of a update and what some people calling legacy might be things not needing updates because they just works and update and replace/drop for the sake of a change does not make things better for no good reason the author of tcpwrapper is Wietse Venema, the perosn who created and maintains postfix - frankly if only 1% of the software out So, you do realise that the same Wietse Venema who wrote and then stopped maintaining tcpwrappers is the one who didn't add *any* tcpwrappers support to Postfix? To this day Postfix doesn't do tcpwrappers. Probably for a good reason, don't you think? until you managed the same stability of interfaces for a couple of years like postfix don't strip quotes most of the replacements in the last few years could have been becakward compatible if the developers would not be too lazy to care about Wietse is such a lazy person that he didn't had hosts.allow/.deny compatibility support to Postfix, isn't he? ask him why 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: Maybe it's time to get rid of tcpwrappers/tcpd?
Am 22.03.2014 03:21, schrieb Lennart Poettering: On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote: DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration). Having a single centralized name-IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead. This is supposedly security functionality. You shouldn't build your security functionality on top of DNS. If you do, then you gain no security in your world one thing rules all true in the world of *layered* security not true 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: Maybe it's time to get rid of tcpwrappers/tcpd?
On 03/22/2014 04:20 AM, Miloslav Trmač wrote: I'm not in this thread to discuss technical merits of the existing implementation. It may be 100% crappy code. /All/ of what you say above may be true, but that being true about a widely-used feature /doesn't automatically mean that eliminating the feature increases securit/y. I'm not even in this thread to object to doing extra work to break users' systems, because you may be right that most users of tcp_wrappers that use it for the DNS functionality shouldn't, and it might be irresponsible for us to support such configurations. I'm participating in this discussion because, as a general rule, I assume most administrators configuring security, and most users in general, /aren't idiots/. So, the fairly large number of assumed non-idiots using this functionality suggests, as a first approximation to truth, that it is useful, and it's the few of us that discuss removal of the feature that are wrong about the consequences of our actions. So here's the thing daemons and applications are inconsistent in their support for libwrap like for example sshd supports it while smbd does not which leads to incorrect configuration and administrative expectation which in itself poses a security risk. The only way administrator can figure out which daemon/service was built with libwrap support, is via ldd/string grep magic since we as an distribution have not provide them with a list which do support it and which do not,nor do we have those component correctly depend on libwrap.so.0. The undisputed fact is you are truly better off security and performance wize using netfilter to solve this which can be done via tcp-wrapper like behavior so... iptables -A INPUT -p tcp --dport port -m iprange --src-range ip-range-iprange -j ACCEPT iptables -A INPUT -p tcp --dport port -j DROP We should have dropped tcp-wrappers as well as denyhosts etc. a long time ago but you know old habits die hard and all that but if FESCo is going to refuse to do that it should ensure at least there will be a list which explains it to adminstrators which component support this and proper package dependency on libwrab for administrators sanity and expectations... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
heads up: plist/usbmux/imobiledevice soname bumps
Hi All, There's a new devel release of the above just landed. I'll be looking to get them into rawhide over the new couple of days but there's been quite some change so I'm going to deal with it all locally first to see what the impact is before I push it. Peter -- 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: Maybe it's time to get rid of tcpwrappers/tcpd?
On Sat, Mar 22, 2014 at 02:59:20AM +0100, Lennart Poettering wrote: No, firewalls don't do DNS-based filtering, since it's a security nightmare. Lennart, this isn't true as a general statement. Both Juniper and Cisco firewalls support FQDN-based access rules. Looks like Palo Alto Networks too although I have not used those. Of course, this doesn't demonstrate that it's a good idea, just that it is actually something people use and which there is demand for. If anything, though, I think this makes me less concerned about deprecating tcp_wrappers since people can find equivalent functionality elsewhere if they want it. (And, I think you could do it on Linux with dnsmasq's ipset functionality if you really wanted to.) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.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: Maybe it's time to get rid of tcpwrappers/tcpd?
On Sat, Mar 22, 2014 at 10:04:51AM +, Jóhann B. Guðmundsson wrote: So here's the thing daemons and applications are inconsistent in their support for libwrap like for example sshd supports it while smbd does not which leads to incorrect configuration and administrative expectation which in itself poses a security risk. That's an excellent point; inconsistency across the distribution is definitely points-off for tcp wrappers. The only way administrator can figure out which daemon/service was built with libwrap support, is via ldd/string grep magic since we as an distribution have not provide them with a list which do support it and which do not,nor do we have those component correctly depend on libwrap.so.0. Can you point to an example of this? Since it is a compiled dynamic library, RPM's automatic dependency checking should get this. Try `repoquery --whatrequires tcp_wrappers-libs`. Speaking of inconsistency, I notice syslog-ng in that list but not rsyslogd. (And as previously noted, there's sendmail and exim, but not postfix.) -- Matthew Miller-- Fedora Project--mat...@fedoraproject.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: Maybe it's time to get rid of tcpwrappers/tcpd?
Am 22.03.2014 07:15, schrieb Reindl Harald: Am 22.03.2014 03:21, schrieb Lennart Poettering: On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote: DNS queries can't really be done within the firewall (and due to the circular dependency between having the firewall up before allowing access to the network and needing access to the network to resolve DNS names, they can't even be used in the on-disk firewall configuration). Having a single centralized name-IP address repository instead of having a redundant copy in each host, and having the configuration use readable names instead of IP addresses, makes some difference in usability and management overhead. This is supposedly security functionality. You shouldn't build your security functionality on top of DNS. If you do, then you gain no security in your world one thing rules all true in the world of *layered* security not true and i will give an example what layered security means * years ago played around with SELinux * after boot SELinux blocked iptables to start * my smb.conf has hosts allow on any machine * i recognized the failed iptables by messages in the samba log about not allowed hosts * guess what happens if you have a guest-share in that case without another security layer so if you propose to remove things which really may not be the best soultion but are a solution in context of layered security you should at the same time propose a replacement which does it better - in context of tcpwrappers a replacement wokring with hosts.allow and hosts.deny and go ahead propose this to be linked with any network aware software in the distribution *that* would be a smart proposal and gains a lot propose to declare things as deprectated while demand from the whole world adopt the changes is a sloppy attitude, frankly can you imagine what people all over the world could have developed on top of Fedora with the time wasted the last few years by adopt changes with no backward compatibility? make proposals and deprecations is easy as long the person who does has not to chew the result by cherry picking what makes the own development easier and cleaner and not care about existing usecases just working until someone breaks them willingly and *please* as long as you don't understand layered security and think a single point of defense resulting in a single point of failure with no additional safety net don't talk too much about security 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: Maybe it's time to get rid of tcpwrappers/tcpd?
Jóhann B. Guðmundsson wrote: So here's the thing daemons and applications are inconsistent in their support for libwrap like for example sshd supports it while smbd does not which leads to incorrect configuration and administrative expectation which in itself poses a security risk. I don't buy that argument. In particular, don't let perfect be the enemy of good, ie, if libwrap isn't perfect = get rid of it, isn't a logical conclusion here (for *this* particular reason at least). -- Rex -- 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: heads up: plist/usbmux/imobiledevice soname bumps
On Sat, Mar 22, 2014 at 6:33 AM, Peter Robinson pbrobin...@gmail.comwrote: Hi All, There's a new devel release of the above just landed. I'll be looking to get them into rawhide over the new couple of days but there's been quite some change so I'm going to deal with it all locally first to see what the impact is before I push it. Glad I read this although I already starting updating the packages for myself. Work just make me get an iPhone when I was perfectly happy with my android phone but it's a 5s and I can't mount it which this update is supposed to fix. Thanks, Richard -- 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: heads up: plist/usbmux/imobiledevice soname bumps
There's a new devel release of the above just landed. I'll be looking to get them into rawhide over the new couple of days but there's been quite some change so I'm going to deal with it all locally first to see what the impact is before I push it. Glad I read this although I already starting updating the packages for myself. Work just make me get an iPhone when I was perfectly happy with my android phone but it's a 5s and I can't mount it which this update is supposed to fix. There's still other components of this update that are missing, I need a new package review [1] if someone can review that, plus there's still some bits for other components that are still landing upstream. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1079663 -- 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: GCJ [was: pdftk retired?]
On Thu, Mar 20, 2014 at 7:24 AM, Andrew Haley wrote: On 03/19/2014 10:59 PM, Andrew Hughes wrote: And JDK5 might be good enough for the use required. It doesn't claim to be anything more than that, so I don't see the harm in leaving it there. Speaking as the upstream maintainer, I do. Hi Andrew, can you be a little more specific about the potential harm you see with keeping GCJ in Fedora? Thanks, Orcan -- 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: Per-Product Config file divergence
Stephen Gallagher wrote: 2) foo-config-cloud remains on the system, irrespective of the presence of fedora-release-cloud That's what's going to happen, because there's nothing that enforces that foo-config-default MUST be the one used by default. It's only preferred at install time due to being the first alternative in the or (assuming the preference algorithm really gets implemented like that), but once another foo-config-* is installed, nothing enforces a switch to -default. Kevin Kofler -- 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: Yet another bug caused by SELinux
Adam Williamson wrote: just to note the facts: this issue could have been resolved much faster, and SELinux is not the reason why it wasn't. But SELinux is the reason the bug was there in the first place. Without SELinux, we wouldn't have had this bug! (Systems without SELinux were not affected, because the broken workaround was only used on systems where allocating the JIT memory normally doesn't work.) Nor the two (separate) critical regressions that plagued F20 and Rawhide recently. Kevin Kofler PS: Et ceterum censeo SELinux esse delendum. -- 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: qmake-qt4 DEFINES issue
Antonio Trande wrote: I need your help with F1LT application[1]. Its latest release (3.0.0) seems not work even if little things are changed in SPEC file. I see you already resolved your problem with upstream's help: https://bitbucket.org/pieczar/f1lt/issue/3/f1lt-commit-7440f9a-does-not-run However, there are several issues in your spec file (not related to this particular issue, but they should be fixed): | Requires(post): gtk2 | Requires(postun): gtk2 should NOT be used. gtk-update-icon-cache is only necessary if GTK+ is actually installed. See: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Icon_Cache Note that no dependencies should be added for this. | BuildRequires: qt-devel = 4.7, desktop-file-utils, dos2unix qt-devel = 4.7 will NOT work as expected, qt-devel has Epoch 1 and so ALL versions of qt-devel are = 4.7. You need either qt-devel = 1:4.7, or, better, qt4-devel = 4.7. (qt4-devel is a Provides in qt-devel.) Using qt4-devel will also work when Qt 5 will become the default (and also on old Fedora/RHEL versions where Qt 3 was the default, but you probably won't find 4.7 available on those). Basically, NEVER BuildRequire qt-devel, ALWAYS use qt4-devel instead. Kevin Kofler -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
Tim Lauridsen wrote: The most common user case would to install a spin with DE you want to use. I dont think it matter much if Gnome software support installation of evironments. most other DE spins uses LightDM, so if you want a more lightweight DE, you don't install the Gnome Desktop first and then install ex. XCFE. Yeah, this idea of having to install GNOME first to be able to install the desktop you actually want is totally wacky, and if that is really what we recommend to our users, they will run to other distributions (that actually support the desktop environment they care about with a dedicated installable live image) in droves. Really, almost all users are NOT going to put up with this. You need to be really determined to want to run Fedora to jump through such ridiculous hoops, most people will just look elsewhere. And this is really true independently of the desktop environment we are talking about (except maybe things such as WM-only setups whose users are used to tweaking things by hand anyway). Kevin Kofler -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
Dennis Jacobfeuerborn wrote: One example is the policy that patches for packages should first be submitted and accepted upstream before they make it into Fedora. That policy is only a non-normative guideline (not part of any enforced Fedora Guidelines or Policies). The decision is purely up to the maintainer(s) of the affected package. This works great because that way you can ensure that once features are added in Fedora it is unlikely that they have to be removed later again because they are rejected upstream. It's terrible though if you want to live on the bleeding edge. Take for example the networking features of OpenStack that required kernel changes that weren't yet committed upstream or the fact that Docker required AUFS for a long time. In both cases Fedora was a terrible platform to develop these technologies because of its conservative stance. In both of these examples, the affected package is the kernel. Blame the kernel maintainers for their strict policies. Those are not Fedora policies. In the AUFS case, there's additionally the problem that FESCo decided a ban on separately-packaged kernel modules as a strictly enforced Fedora policy. At the time this was decided, the understanding was that it should be possible to get needed modules into the kernel package instead. However, the kernel maintainers simply vetoed ALL non-upstream kernel modules that came up do far. They do not build even the modules in the upstream staging tree! The ban on separate kmod-* packages really needs to be repealed (for modules with GPLv2-compatible licensing), and the current RPM Fusion kmod v2 system picked up as a Fedora policy. We allow separate plugin packages for any other application with a plugin system; I do not see any reason why the kernel has to be special there. Kevin Kofler -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
Miloslav Trmač wrote: When we say that there should be high bar for becoming a Fedora Product, that means that there should be few of them, I see this repeated over and over by several people. This strikes me as quite the opposite of being inclusive. IMHO, ALL the current Spins should automatically become Products (or the whole Products idea dropped in favor of the existing Spins system that just worked). Kevin Kofler -- 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
On 23.03.2014 03:45, Kevin Kofler wrote: Dennis Jacobfeuerborn wrote: One example is the policy that patches for packages should first be submitted and accepted upstream before they make it into Fedora. That policy is only a non-normative guideline (not part of any enforced Fedora Guidelines or Policies). The decision is purely up to the maintainer(s) of the affected package. This works great because that way you can ensure that once features are added in Fedora it is unlikely that they have to be removed later again because they are rejected upstream. It's terrible though if you want to live on the bleeding edge. Take for example the networking features of OpenStack that required kernel changes that weren't yet committed upstream or the fact that Docker required AUFS for a long time. In both cases Fedora was a terrible platform to develop these technologies because of its conservative stance. In both of these examples, the affected package is the kernel. Blame the kernel maintainers for their strict policies. Those are not Fedora policies. In the AUFS case, there's additionally the problem that FESCo decided a ban on separately-packaged kernel modules as a strictly enforced Fedora policy. At the time this was decided, the understanding was that it should be possible to get needed modules into the kernel package instead. However, the kernel maintainers simply vetoed ALL non-upstream kernel modules that came up do far. They do not build even the modules in the upstream staging tree! The ban on separate kmod-* packages really needs to be repealed (for modules with GPLv2-compatible licensing), and the current RPM Fusion kmod v2 system picked up as a Fedora policy. We allow separate plugin packages for any other application with a plugin system; I do not see any reason why the kernel has to be special there. But not every change can be implemented purely as a module. This is precisely why I think the one package to rule them all policy should be changed for Fedora products. That way you can have the current kernel package policies for the regular kernel that all products by default use but the products that have specific needs can deliver their own kernel package with the required patches. As a result these products obviously also carry the responsibility for any problems that result from these changes. That would allow products to act as incubators for new ideas and technologies and when these things have matured may everntually be folded into the core of Fedora. Regards, Dennis -- 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-Catalyst-Controller-HTML-FormFu
perl-Catalyst-Controller-HTML-FormFu has broken dependencies in the rawhide tree: On x86_64: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On i386: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) On armhfp: perl-Catalyst-Controller-HTML-FormFu-0.09004-4.fc20.noarch requires perl(HTML::FormFu::MultiForm) 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-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-All] Created tag perl-IO-All-0.60-1.fc21
The lightweight tag 'perl-IO-All-0.60-1.fc21' was created pointing to: e0068c2... Update to 0.60 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Update to 1.971
commit 04c77f6f736abd698e2a2809c5ad72fe2fa05bd7
Author: Paul Howarth p...@city-fan.org
Date: Sat Mar 22 21:38:07 2014 +
Update to 1.971
- New upstream release 1.971
- Try to use SSL_hostname for hostname verification if no
SSL_verifycn_name
is given; this way, hostname for SNI and verification can be specified
in
one step
- New test program example/simulate_proxy.pl
perl-IO-Socket-SSL.spec |9 -
sources |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index f54f916..eb13f56 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.970
+Version: 1.971
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -72,6 +72,13 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL::Utils.3pm*
%changelog
+* Sat Mar 22 2014 Paul Howarth p...@city-fan.org - 1.971-1
+- Update to 1.971
+ - Try to use SSL_hostname for hostname verification if no SSL_verifycn_name
+is given; this way, hostname for SNI and verification can be specified in
+one step
+ - New test program example/simulate_proxy.pl
+
* Wed Mar 19 2014 Paul Howarth p...@city-fan.org - 1.970-1
- Update to 1.970
- Make sure sub default_ca uses a local $_ and not a version of an outer
diff --git a/sources b/sources
index 4d7fe1d..8dce4fc 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-27c275f893017873842caa5082399394 IO-Socket-SSL-1.970.tar.gz
+0bdaf4a9b1f5f2a76e99ca4a3bd52d3d IO-Socket-SSL-1.971.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-DBIx-Class
perl-DBIx-Class has broken dependencies in the epel-6 tree: On ppc64: perl-DBIx-Class-0.08123-2.el6.noarch requires perl(Class::Trigger) 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
