Broken dependencies: dspam
dspam has broken dependencies in the epel-7 tree: On x86_64: dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) On ppc64: dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) On x86_64: dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::bars) On ppc64: dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::bars) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-PDL
perl-PDL has broken dependencies in the epel-7 tree: On x86_64: perl-PDL-2.7.0-2.el7.1.x86_64 requires perl(Prima::MsgBox) On ppc64: perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(Prima::MsgBox) perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: w3c-markup-validator
w3c-markup-validator has broken dependencies in the epel-7 tree: On x86_64: w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) On ppc64: w3c-markup-validator-1.3-4.el7.noarch requires perl(SGML::Parser::OpenSP) = 0:0.991 w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) On x86_64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds On ppc64: w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
EPEL epel beta report: 20140207 changes
Compose started at Fri Feb 7 08:15:03 UTC 2014 Broken deps for x86_64 -- bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.x86_64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.x86_64 requires nagios check-mk-1.2.2p2-2.el7.x86_64 requires mod_python dspam-3.10.2-9.el7.x86_64 requires perl(Mail::MboxParser) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.x86_64 requires perl(GD::Graph::bars) erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript 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 imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst lua-lxc-0.9.0-3.el7.x86_64 requires lua-filesystem 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 nagios-plugins-nrpe-2.15-1.el7.x86_64 requires nagios-plugins nrpe-2.15-1.el7.x86_64 requires nagios-common openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg perl-PDL-2.7.0-2.el7.1.x86_64 requires perl(Prima::MsgBox) postgrey-1.34-12.el7.noarch requires perl(Net::Server::Multiplex) postgrey-1.34-12.el7.noarch requires perl(Net::Server::Daemonize) postgrey-1.34-12.el7.noarch requires perl(Net::Server) postgrey-1.34-12.el7.noarch requires perl(BerkeleyDB) python-social-auth-0.1.19-1.el7.noarch requires python-requests-oauthlib = 0:0.3.0 python-social-auth-0.1.19-1.el7.noarch requires python-oauthlib = 0:0.3.8 python-sphinxcontrib-httpdomain-1.1.8-3.el7.noarch requires python-sphinx10 qpid-cpp-server-ha-0.24-9.el7.x86_64 requires qpid-qmf(x86-64) qpid-tools-0.24-9.el7.noarch requires python-qpid-qmf 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 snmptt-1.4-0.9.beta2.el7.noarch requires perl-Net-SNMP spectrwm-2.4.0-2.el7.x86_64 requires xlockmore spectrwm-2.4.0-2.el7.x86_64 requires dmenu supervisor-3.0-1.el7.noarch requires python-meld3 = 0:0.6.5 w3c-markup-validator-1.3-4.el7.noarch requires perl(HTML::Template) w3c-markup-validator-libs-1.3-4.el7.noarch requires html401-dtds Broken deps for ppc64 -- TurboGears-1.1.3-8.el7.noarch requires python-simplejson = 0:1.9.1 bodhi-client-0.9.7-1.el7.noarch requires python-simplejson bodhi-server-0.9.7-1.el7.noarch requires python-simplemediawiki 1:centerim-4.22.10-14.el7.ppc64 requires perl(Time::ParseDate) check-mk-1.2.2p2-2.el7.ppc64 requires nagios check-mk-1.2.2p2-2.el7.ppc64 requires mod_python dspam-3.10.2-9.el7.ppc64 requires perl(Mail::MboxParser) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines3d) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::lines) dspam-web-3.10.2-9.el7.ppc64 requires perl(GD::Graph::bars) erlang-rpm-macros-0.1.3-6.el7.noarch requires /usr/bin/escript fedmsg-0.7.2-1.el7.noarch requires python-simplejson fedmsg-0.7.2-1.el7.noarch requires python-requests globus-gram-job-manager-pbs-1.6-7.el7.ppc64 requires torque-client globus-gram-job-manager-sge-1.7-2.el7.ppc64 requires gridengine httpie-0.8.0-1.el7.noarch requires python-requests imapsync-1.580-1.el7.noarch requires perl(Data::Uniqid) imapsync-1.580-1.el7.noarch requires perl(Authen::NTLM) koji-vm-1.8.0-2.el7.noarch requires python-virtinst lua-lxc-0.9.0-3.el7.ppc64 requires lua-filesystem lxc-templates-0.9.0-3.el7.ppc64 requires dpkg lxc-templates-0.9.0-3.el7.ppc64 requires debootstrap lxc-templates-0.9.0-3.el7.ppc64 requires busybox nagios-plugins-nrpe-2.15-1.el7.ppc64 requires nagios-plugins nrpe-2.15-1.el7.ppc64 requires nagios-common openpgpkey-milter-0.3-1.el7.noarch requires python-pymilter openpgpkey-milter-0.3-1.el7.noarch requires python-gnupg perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(Prima::MsgBox) perl-PDL-2.7.0-2.el7.1.ppc64 requires perl(PDL::Slatec) postgrey-1.34-12.el7.noarch requires perl(Net::Server::Multiplex)
EPEL sftp module in proftpd
Hello, Is it possible to build sftp module in proftpd package by default? It is very uncomfortable to rebuild proftpd each time only for one module. Thanks in advance ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Heads-up: updating python-sphinx to 1.2.1 in Rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear all, Unless there are objections, I will be updating the python-sphinx documentation generator in Rawhide to the latest 1.2.1 release. For the convenience of maintainers of affected packages, here are the incompatible changes since 1.1.3, pulled from http://sphinx-doc.org/changes.html: 1.2: Removed the sphinx.ext.refcounting extension ? it is very specific to CPython and has no place in the main distribution. 1.2 beta3: PR#154: Remove ?sphinx? prefix from LaTeX class name except ?sphinxmanual? and ?sphinxhowto?. Now you can use your custom document class without ?sphinx? prefix. Thanks to Erik B. 1.2 beta2: PR#144, #1182: Force timezone offset to LocalTimeZone on POT-Creation-Date that was generated by gettext builder. Thanks to masklinn and Jakub Wilk. 1.2 beta1: Removed sphinx.util.compat.directive_dwim() and sphinx.roles.xfileref_role() which were deprecated since version 1.0. PR#122: the files given in latex_additional_files now override TeX files included by Sphinx, such as sphinx.sty. PR#124: the node generated by versionadded, versionchanged and deprecated directives now includes all added markup (such as ?New in version X?) as child nodes, and no additional text must be generated by writers. PR#99: the seealso directive now generates admonition nodes instead of the custom seealso node. Affected packages (maintainers will need to double-check, and chime in if they would prefer the update be deferred): Mayavi-0:4.3.0-8.gitf8f2c40.fc20.src ReviewBoard-0:1.7.18-1.fc20.src ReviewBoard-0:1.7.21-1.fc20.src StarCluster-0:0.-0.4.0.94.fc20.src ViTables-0:2.1-7.fc20.src abrt-0:2.1.9-1.fc20.src abrt-0:2.1.12-1.fc20.src apiextractor-0:0.10.10-5.fc20.src aqsis-0:1.8.2-6.fc20.src autotest-framework-0:0.16.0-1.fc20.src babel-0:1.3-2.fc20.src bcfg2-0:1.3.2-2.fc20.src bcfg2-0:1.3.3-3.fc20.src bcfg2-0:1.3.3-4.fc20.src botan-0:1.10.5-4.fc20.src bpython-0:0.12-3.fc20.src bpython-0:0.12-4.fc20.src buildbot-0:0.8.8-1.fc20.src bzr-0:2.6.0-2.fc20.src catkin-0:0.4.5-8.gitd4f1f24.fc20.src dnf-0:0.4.8-1.fc20.src dnf-0:0.4.12-1.fc20.src flexiport-0:2.0.0-5.20120701git1b6103d.fc20.src gcc-python-plugin-0:0.12-15.fc20.src generatorrunner-0:0.6.16-4.fc20.src git-cola-0:1.9.1-1.fc20.src git-cola-0:1.9.3-1.fc20.src glom-0:1.22.1-6.fc20.src glom-0:1.24.2-1.fc20.src h5py-0:2.2.0-1.fc20.src h5py-0:2.2.1-1.fc20.src hawkey-0:0.4.5-1.fc20.src hawkey-0:0.4.9-1.fc20.src hokuyoaist-0:3.0.1-3.20120729git69df78b.fc20.src jansson-0:2.4-3.fc20.src krb5-0:1.11.3-33.fc20.src krb5-0:1.11.3-39.fc20.src libmemcached-0:1.0.16-1.fc20.src libmemcached-0:1.0.16-2.fc20.src librepo-0:1.4.0-1.fc20.src librepo-0:1.5.1-1.fc20.src librepo-0:1.5.2-2.fc20.src metrics-0:3.0.1-1.fc20.src moksha-0:1.0.0-8.fc20.src offlineimap-0:6.5.2.1-5.fc20.src offlineimap-0:6.5.5-1.fc20.src opencv-0:2.4.6.1-1.fc20.src opencv-0:2.4.7-2.fc20.src openlmi-networking-0:0.2.1-1.fc20.src openlmi-networking-0:0.2.2-2.fc20.src openlmi-providers-0:0.4.1-2.fc20.src openlmi-providers-0:0.4.2-2.fc20.src openlmi-scripts-0:0.2.4a-3.fc20.src openlmi-scripts-0:0.2.6-5.fc20.src openlmi-storage-0:0.7.0-2.fc20.src openlmi-storage-0:0.7.1-1.fc20.src openlmi-tools-0:0.8-1.fc20.src openlmi-tools-0:0.9-16.fc20.src openstack-ceilometer-0:2013.2-1.fc20.src openstack-ceilometer-0:2013.2.1-1.fc20.src openstack-ceilometer-0:2013.2.1-2.fc20.src openstack-cinder-0:2013.2-1.fc20.src openstack-cinder-0:2013.2.1-1.fc20.src openstack-glance-0:2013.2-1.fc20.src openstack-glance-0:2013.2.1-1.fc20.src openstack-heat-0:2013.2-0.5.b2.fc20.src openstack-heat-0:2013.2.1-1.0.fc20.src openstack-keystone-0:2013.2-0.9.b3.fc20.src openstack-keystone-0:2013.2.1-1.fc20.src openstack-nova-0:2013.2-2.fc20.src openstack-nova-0:2013.2.1-4.fc20.src openstack-packstack-0:2013.2.1-0.5.dev740.fc20.src openstack-packstack-0:2013.2.1-0.29.dev956.fc20.src openstack-savanna-0:0.2-3.fc20.src openstack-swift-0:1.10.0-2.fc20.src pcl-0:1.7.0-4.fc20.src powerline-0:0.0.1-6.20131123gitdb80fc.fc20.src psi4-0:4.0-0.8.b5.fc20.src pykka-0:1.1.0-2.fc20.src pyrasite-0:2.0-5.fc20.src pytest-0:2.4.2-2.fc20.src python-AppTools-0:4.2.0-2.fc20.src python-Bottleneck-0:0.6.0-1.fc20.src python-SecretStorage-0:1.1.0-1.fc20.src python-amqp-0:1.3.3-1.fc20.src python-arc-0:0.7.1-1.fc20.src python-astropy-0:0.3-7.fc20.src python-behave-0:1.2.3-7.fc20.src python-behave-0:1.2.3-8.fc20.src python-ceilometerclient-0:1.0.6-1.fc20.src python-ceilometerclient-0:1.0.8-1.fc20.src python-cffi-0:0.6-5.fc20.src python-chameleon-0:2.11-3.fc20.src python-cinderclient-0:1.0.7-1.fc20.src python-cinderclient-0:1.0.7-2.fc20.src python-cliapp-0:1.20130613-2.fc20.src python-cliapp-0:1.20130808-1.fc20.src python-cloud-sptheme-0:1.5-3.fc20.src python-cloudservers-0:1.2-7.fc20.src python-cvxopt-0:1.1.6-2.fc20.src python-django-0:1.5.5-2.fc20.src python-django-appconf-0:0.6-2.fc20.src python-django-horizon-0:2013.2-2.fc20.src
Re: EPEL sftp module in proftpd
On Fri, Feb 07, 2014 at 10:44:46AM +0200, Alex Domoradov wrote: Is it possible to build sftp module in proftpd package by default? It is very uncomfortable to rebuild proftpd each time only for one module. It is included/built by default in the EPEL package, so I am not sure what you mean: http://koji.fedoraproject.org/koji/rpminfo?rpmID=4689710 Regards Till ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Auto-expiring bugs are getting absurd
On Thu, Feb 06, 2014 at 11:54:30PM -0800, Adam Williamson wrote: What is the underlying problem here anyway? I've never been hugely convinced there is one, but the problem people *claim* there is is that closing bugs on EOL releases gives a bad impression to people who report the bugs. We're terrible at numbers, but subjectively, people complain to me about this at conferences a lot. Why do you think they're any more likely to get a response if the bug stays open? Here's one case: a relatively stable package where there are small RFE bugs, or spelling fixes, or packaging improvements which are clearly right but have low practical impact. These are good things to do, but maybe the maintainer doesn't have lot of time for that particular package. A new upstream version comes out every couple of years. When that update happens, the maintainer might do an update, and look through all the open bugs to make sure they're covered. If they got auto-closed, it never happens. I know ideally maintainers should be making those changes in rawhide all the time as the bugs come in, but time. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. We already don't have enough time to look after all the open bugs we have. Why are things going to be better if we have more? Yeah, closed or open, it would be nice to have better triage, but that's a huge job with very little reward and extremely high burnout. As I said at the end of my other message with the handwaving, if someone has a clever way to automatically identify the most important candidates from the thousands, that would be very useful. -- 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: Auto-expiring bugs are getting absurd
On Fri, 2014-02-07 at 04:26 -0500, Matthew Miller wrote: On Thu, Feb 06, 2014 at 11:54:30PM -0800, Adam Williamson wrote: What is the underlying problem here anyway? I've never been hugely convinced there is one, but the problem people *claim* there is is that closing bugs on EOL releases gives a bad impression to people who report the bugs. We're terrible at numbers, but subjectively, people complain to me about this at conferences a lot. Why do you think they're any more likely to get a response if the bug stays open? Here's one case: a relatively stable package where there are small RFE bugs, or spelling fixes, or packaging improvements which are clearly right but have low practical impact. There is a kind of magic trick for this: if you set a bug to be against Rawhide and give it the FutureFeature keyword (which is our 'official way' of identifying RFEs), it won't ever be re-based to a stable release at Branch time, and hence won't ever get EOLed. That's a bit secret sauce-y, though. These are good things to do, but maybe the maintainer doesn't have lot of time for that particular package. A new upstream version comes out every couple of years. When that update happens, the maintainer might do an update, and look through all the open bugs to make sure they're covered. If they got auto-closed, it never happens. I know ideally maintainers should be making those changes in rawhide all the time as the bugs come in, but time. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. We already don't have enough time to look after all the open bugs we have. Why are things going to be better if we have more? Yeah, closed or open, it would be nice to have better triage, but that's a huge job with very little reward and extremely high burnout. Yep. And there always seems to be something more immediately useful to do. But even if we triage the bug load, that doesn't mean we have any *fewer* open bugs, it just means we maybe do a better job of fixing the most important ones first. The same absolute number of bugs is likely to go unaddressed as is unaddressed at present. As I said at the end of my other message with the handwaving, if someone has a clever way to automatically identify the most important candidates from the thousands, that would be very useful. I would also like that. And my golden toilet. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Auto-expiring bugs are getting absurd
On Fri, Feb 07, 2014 at 01:33:31AM -0800, Adam Williamson wrote: There is a kind of magic trick for this: if you set a bug to be against Rawhide and give it the FutureFeature keyword (which is our 'official way' of identifying RFEs), it won't ever be re-based to a stable release at Branch time, and hence won't ever get EOLed. That's a bit secret sauce-y, though. Huh, cool. *goes off to add that to a bunch of open bugs against my packages*. -- 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
[Bug 1060465] Review Request: perl-Excel-Writer-XLSX - Create a new file in the Excel 2007+ XLSX format
https://bugzilla.redhat.com/show_bug.cgi?id=1060465 --- Comment #4 from David Dick dd...@cpan.org --- The Spec and SRPM files have been updated and built on koji at https://koji.fedoraproject.org/koji/taskinfo?taskID=6503548 -- 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=7c8IZo7Tn4a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Self-Introduction / Review requests: ocaml dependencies of 0install
Thanks to Jerry James, I'm down to three reviews that needs to be done for the 0install update. any taker appreciate, will review any of your requests in exchange. Best regards, ~ michel On 01/20/2014 02:57 PM, Michel Alexandre Salim wrote: * ocaml-xmlm - A streaming XML codec https://bugzilla.redhat.com/show_bug.cgi?id=1055395 * ocaml-yojson - An optimized parsing and printing library for the JSON format https://bugzilla.redhat.com/show_bug.cgi?id=1055396 * 0install - A decentralized cross-distribution software installation system https://bugzilla.redhat.com/show_bug.cgi?id=1055398 (rename/re-review request from zeroinstall-injector) Let me know if I can in turn help review other submissions. Best regards, -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: michel-...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Auto-expiring bugs are getting absurd
- Original Message - From: Michael Schwendt mschwe...@gmail.com To: devel@lists.fedoraproject.org Sent: Thursday, February 6, 2014 2:21:53 PM Subject: Re: Auto-expiring bugs are getting absurd On Wed, 05 Feb 2014 14:50:59 -0800, Adam Williamson wrote: On Wed, 2014-02-05 at 22:48 +, Colin Macdonald wrote: On 05/02/14 22:42, David Timothy Strauss wrote: This is also not the first time this has happened to me. I'll chime in: when I first switched to Fedora (F14/15 era), I found this quite obnoxious, enough that I remember it. So there is also an issue of being a welcoming community to newcomers. The problem is that no-one seems to come up with an alternative that's any better. Leaving bugs on EOL versions open to rot away and be ignored is no use. We *could* give everyone privs to re-open closed bugs, I guess, and I personally don't think that would end terribly, but it's kind of a radical plan. The idea of not closing bugs that have comments after the EOL notification doesn't necessarily make things better, I don't think; we'd just have errors in the other direction. Say someone dropped a note 'oh yeah, this is working now!' - it would be silly not to close the bug, right? Has that been tried before? It sounds like a better approach. Where is the human to notice comments after EOL and act accordingly? How many tickets would be affected by a comment after EOL? What is the underlying problem here anyway? Too many unhandled tickets - EOL auto-close threatening - too many closed tickets to handle - how to escape from that loop? In several large upstream bug trackers it is no different. Are developers always informed about what doesn't work even when not responding to tickets? Why should users still take the time to submit problem reports if they don't get a response? Let me state the other side - out of maybe 20-30 requests for more information from reporters I get one or even none additional information in the bugs. This is not motivating for developers to look at bug reports also. Why should packagers spend time trying to clarify what the problem is exactly if they don't get a response after the bug is open? I'm even looking in the other direction if there is request for information from the assignee of the bug and there is none given the bug should be auto-closed (time period to be decided - 3 months sounds more feasible). This would be more helpful to people that fix bugs and triage their bugzillas too. Due to triaging many such bugs it makes it impossible for me to keep the pace and the very few good bugs (with enough information) are lost sometimes in the huge number of bugs so good reporters get upset. It's unfortunate that this happen but my personal experience is that 90% of reporters are unwilling to spend time helping reproducing the problem which makes the reports useless most of the time. Alexander Kurtakov algorithms are never perfect, but we do have to use them, as a perennially under-resourced project. I've posted about it in 2008 already, and I still think the auto-closing leads to hiding crap under the carpet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: f20, anaconda, net install and video out of range ....
Adam Williamson (awill...@redhat.com) said: On Mon, 2014-02-03 at 14:28 -0500, Adam Jackson wrote: Why would it not install xorg-x11-drv-cirrus when it sees the physical card? We don't have anything like the kernel's modaliases for X drivers, at least not exposed in a way anaconda could use. Of course, it's possible to do this. all you need is some poor sap to maintain something like this: http://svnweb.mageia.org/soft/ldetect-lst/trunk/lst/pcitable?view=markup ... Of course, we're 'just' talking about one case, but once you start building this kind of manual device/driver table, it tends to take on a mind of its own and start multiplying. You could say it starts multiplying and spreading like a invasive weed, even. I'm rather attached to the policy of Just Saying No. *nod* If you have a specific explicit quirk in terms of don't use XYZ for the virt cirrus, it's probably best done in the driver itself. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1062576] New: memory leak when including a file with use utf8
https://bugzilla.redhat.com/show_bug.cgi?id=1062576
Bug ID: 1062576
Summary: memory leak when including a file with use utf8
Product: Fedora
Version: 19
Component: perl
Severity: medium
Assignee: jples...@redhat.com
Reporter: l...@yars.free.net
QA Contact: extras...@fedoraproject.org
CC: cw...@alumni.drew.edu, iarn...@gmail.com,
jples...@redhat.com, ka...@ucw.cz,
perl-de...@lists.fedoraproject.org, ppi...@redhat.com,
psab...@redhat.com, rc040...@freenet.de,
tcall...@redhat.com
Description of problem:
Every time perl includes a file with use utf8 and text constants it leaks
memory.
Version-Release number of selected component (if applicable):
perl-5.16.3-266.fc19.x86_64
How reproducible:
always
Steps to Reproduce:
1. run the test program below
2. watch as memory usage grows
Here is the test program:
-
my $mem = 0;
sub report_memory () {
my $next_mem = qx[ps -p $$ -o size=]+0;
printf %+8d = %8d K\n, $next_mem-$mem, $next_mem; $mem = $next_mem;
}
for (0..1e5) {
do 'x.inc';
report_memory unless $_ % 1e4;
}
-
x.inc contains:
-
use utf8;
$x='x';
-
--
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=l7ghbj1UQEa=cc_unsubscribe
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Gsoc idea feedback and suggestions.
Le Jeu 6 février 2014 21:38, Vidhun Vinod a écrit : 1. Most of the hosting companies do not support web-sockets. And this is unlikely to change. People deployed firewalls for a reason and I can't fathom why the web sockets guys actually expected that wrapping protocols people didn't trust in a browser wrapper would actually result in them being authorised in security equipments. (now that I think about it, that's the same delusion as isvs that think creating a new distro-stamped diffusion process that lacks traditional disto constrains will get them the trust of traditional distro packages). Regards, -- Nicolas Mailhot -- 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: Adjust wiki for ARM BeagleBone Black
This was well intention wiki edit, and possibly unaware of in-flight changes about to land in Fedora u-boot implementation. We are transitioning to extlinux which has better integration with other parts of Fedora, and is arguably more user friendly. It works similar to syslinux, the menu system on our ISO images, etc. No problem, the edit is probably fine until we have the time to go through the site and mass edit for the stuff. Thanks Marcelo. -Jon Disnard FAS: parasense IRC: masta On Fri, Feb 7, 2014 at 12:30 AM, Dennis Gilmore den...@ausil.us wrote: That's not necessary abcboard is not used and has been removed from newer uboot builds uEnv.text files. Dennis On February 7, 2014 3:13:27 AM CET, Marcelo Barbosa fireman...@fedoraproject.org wrote: Peter, Changed in this part: Change one option in this file(only BeagleBone Black): vi /run/media/$USER/uboot/uEnv.txt abcboard=am335x-bone abcboard=am335x-boneblack Added. firemanxbr On Thu, Feb 6, 2014 at 9:32 PM, Peter Robinson pbrobin...@gmail.com wrote: I adjusted this documentation in wiki: https://fedoraproject.org/wiki/Architectures/ARM/F20/Installation#For_the_BeagleBone_Black Added this important step to create image of Fedora 20 for BeagleBone Black board. this important step being what exactly? 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- 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: Auto-expiring bugs are getting absurd
On Thu, 2014-02-06 at 23:54 -0800, Adam Williamson wrote: On Thu, 2014-02-06 at 13:21 +0100, Michael Schwendt wrote: Where is the human to notice comments after EOL and act accordingly? In practice, GNOME maintainers have hundreds of bugs apiece and so rarely respond to individual bug reports, even simple requests to close or reopen a bug. Also many GNOME bugs are assigned to the Red Hat email address of somebody who I believe no longer works at Red Hat How many tickets would be affected by a comment after EOL? Don't know, probably wouldn't be too hard to look. I think this is a bad idea: what happens when users comment to say that the bug is resolved and can be closed? 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: Adjust wiki for ARM BeagleBone Black
On Fri, Feb 7, 2014 at 2:43 PM, Jon jdisn...@gmail.com wrote: This was well intention wiki edit, and possibly unaware of in-flight changes about to land in Fedora u-boot implementation. We are transitioning to extlinux which has better integration with other parts of Fedora, and is arguably more user friendly. It works similar to syslinux, the menu system on our ISO images, etc. No problem, the edit is probably fine until we have the time to go through the site and mass edit for the stuff. Well the extlinux change will be in F-21 so until that's released it's perfectly valid and will be for a number of months yet -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Module-Find-0.12.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Module-Find: abd614f3ebca68b4e7cc474400a8c0f2 Module-Find-0.12.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Find] Update to 0.12
commit 4a51b3e14be9eca33a2d7af97e4728aae4c1f146
Author: Paul Howarth p...@city-fan.org
Date: Fri Feb 7 15:30:02 2014 +
Update to 0.12
- New upstream release 0.12
- Fixed CPAN RT#81077: useall fails in taint mode
- Fixed CPAN RT#83596: Documentation doesn't describe behaviour if a
module
fails to load
- Clarified documentation for useall and usesub
- Fixed CPAN RT#62923: setmoduledirs(undef) doesn't reset to searching
@INC
- Added more explicit tests
perl-Module-Find.spec | 13 +++--
sources |2 +-
2 files changed, 12 insertions(+), 3 deletions(-)
---
diff --git a/perl-Module-Find.spec b/perl-Module-Find.spec
index 0d255ff..c97f086 100644
--- a/perl-Module-Find.spec
+++ b/perl-Module-Find.spec
@@ -1,6 +1,6 @@
Name: perl-Module-Find
-Version: 0.11
-Release: 7%{?dist}
+Version: 0.12
+Release: 1%{?dist}
Summary: Find and use installed modules in a (sub)category
Group: Development/Libraries
License: GPL+ or Artistic
@@ -53,6 +53,15 @@ rm -rf %{buildroot}
%{_mandir}/man3/Module::Find.3pm*
%changelog
+* Fri Feb 7 2014 Paul Howarth p...@city-fan.org - 0.12-1
+- Update to 0.12:
+ - Fixed CPAN RT#81077: useall fails in taint mode
+ - Fixed CPAN RT#83596: Documentation doesn't describe behaviour if a module
+fails to load
+ - Clarified documentation for useall and usesub
+ - Fixed CPAN RT#62923: setmoduledirs(undef) doesn't reset to searching @INC
+ - Added more explicit tests
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.11-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 9cdd614..6a337ca 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-420a0796a1fbdfd5704df754872db7e1 Module-Find-0.11.tar.gz
+abd614f3ebca68b4e7cc474400a8c0f2 Module-Find-0.12.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Find] Created tag perl-Module-Find-0.12-1.el7
The lightweight tag 'perl-Module-Find-0.12-1.el7' was created pointing to: 4a51b3e... Update to 0.12 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Module-Find] Created tag perl-Module-Find-0.12-1.fc21
The lightweight tag 'perl-Module-Find-0.12-1.fc21' was created pointing to: 4a51b3e... Update to 0.12 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File IO-Socket-SSL-1.967.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 78b84d50e5a04c19b1d3835514dece95 IO-Socket-SSL-1.967.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Update to 1.967
commit 961f407eff217ef1ccdaf50a949215bccaa1cc85
Author: Paul Howarth p...@city-fan.org
Date: Fri Feb 7 15:58:48 2014 +
Update to 1.967
- New upstream release 1.967
- Verify the hostname inside a certificate by default with a superset of
common verification schemes instead of not verifying identity at all;
for
now it will only complain if name verification failed but in the future
it
will fail certificate verification, forcing you to set the expected
SSL_verifycn_name if you want to accept the certificate
- New option SSL_fingerprint and new methods get_fingerprint and
get_fingerprint_bin; together they can be used to selectively accept
specific certificates that would otherwise fail verification, like
self-signed, outdated or from unknown CAs
- Utils:
- Default RSA key length 2048
- Digest algorithm to sign certificate in CERT_create can be given;
defaults to SHA-256
- CERT_create can now issue non-CA self-signed certificate
- CERT_create add some more useful constraints to certificate
- Spelling fixes
perl-IO-Socket-SSL.spec | 22 +-
sources |2 +-
2 files changed, 22 insertions(+), 2 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index e82f9a0..6f3f63f 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,5 +1,5 @@
Name: perl-IO-Socket-SSL
-Version: 1.966
+Version: 1.967
Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
@@ -23,6 +23,7 @@ BuildRequires:perl(Net::SSLeay) = 1.46
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Socket)
BuildRequires: perl(Socket6)
+BuildRequires: perl(Test::More)
BuildRequires: procps
# Use IO::Socket::IP for IPv6 support where available, else IO::Socket::INET6
%if 0%{?fedora} 15 || 0%{?rhel} 6
@@ -71,6 +72,25 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL::Utils.3pm*
%changelog
+* Fri Feb 7 2014 Paul Howarth p...@city-fan.org - 1.967-1
+- Update to 1.967
+ - Verify the hostname inside a certificate by default with a superset of
+common verification schemes instead of not verifying identity at all; for
+now it will only complain if name verification failed but in the future it
+will fail certificate verification, forcing you to set the expected
+SSL_verifycn_name if you want to accept the certificate
+ - New option SSL_fingerprint and new methods get_fingerprint and
+get_fingerprint_bin; together they can be used to selectively accept
+specific certificates that would otherwise fail verification, like
+self-signed, outdated or from unknown CAs
+ - Utils:
+- Default RSA key length 2048
+- Digest algorithm to sign certificate in CERT_create can be given;
+ defaults to SHA-256
+- CERT_create can now issue non-CA self-signed certificate
+- CERT_create add some more useful constraints to certificate
+ - Spelling fixes
+
* Wed Jan 22 2014 Paul Howarth p...@city-fan.org - 1.966-1
- Update to 1.966
- Fixed bug introduced in 1.964 - disabling TLSv1_2 no longer worked by
diff --git a/sources b/sources
index e2cccd4..5e1dad4 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-af82b20feb6633f1a707d40dbbf7f590 IO-Socket-SSL-1.966.tar.gz
+78b84d50e5a04c19b1d3835514dece95 IO-Socket-SSL-1.967.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.967-1.fc21
The lightweight tag 'perl-IO-Socket-SSL-1.967-1.fc21' was created pointing to: 961f407... Update to 1.967 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: f20, anaconda, net install and video out of range ....
On Thu, 6 Feb 2014, Adam Williamson wrote: painstakingly hand-weeding something like M*a's ldetect-lst you can get some minor benefits, like doing this kind of distinction where we want to load the native driver for a real card but not qemu's emulated cirrus. You are telling me it is hard to detect the real physical card versus the emulated card? Come on! You can even make that decision by looking at the cpu type. If your cpu is QEMU Virtual CPU, how about using the virtual cirrus driver Taking out everyone who tries to run fedora or rhel7 using a physical cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III servers with SCSI disks and cirrus cards. In fact, I think you will see it more within the enterprise then outside it. Paul -- 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: f20, anaconda, net install and video out of range ....
Am 07.02.2014 17:19, schrieb Paul Wouters: On Thu, 6 Feb 2014, Adam Williamson wrote: painstakingly hand-weeding something like M*a's ldetect-lst you can get some minor benefits, like doing this kind of distinction where we want to load the native driver for a real card but not qemu's emulated cirrus. You are telling me it is hard to detect the real physical card versus the emulated card? Come on! You can even make that decision by looking at the cpu type. If your cpu is QEMU Virtual CPU, how about using the virtual cirrus driver correct Taking out everyone who tries to run fedora or rhel7 using a physical cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III servers with SCSI disks and cirrus cards. In fact, I think you will see it more within the enterprise then outside it you expect RHEL7 running on a PIII? this train has passed by long ago http://www.linux-mag.com/id/7618/ Although its still called the “i386″ architecture, the 32bit version has been built for i686 processors and later, as well as being optimized for the Atom processor. This was done by setting the GCC CFLAGS to “-march=i686 -mtune=atom”. As such, Fedora loses the ability to run on i586 and older computers, but gains performance on popular Atom based netbooks. 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
File Test-Synopsis-0.10.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Synopsis: 9b9f333678d51e32966538b380e3cc41 Test-Synopsis-0.10.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Synopsis] Update to 0.10
commit eec08e2f72b287a8a77b9c9b81c4e8490ed0
Author: Paul Howarth p...@city-fan.org
Date: Fri Feb 7 16:41:19 2014 +
Update to 0.10
- New upstream release 0.10
- Fixed prereqs to allow earlier versions of Test-Simple (Issue #9)
- Removed POD errors from test .pm's to increase Kwalitee
- Reverted the change of renaming extract_synopsis() to
_extract_synopsis(),
as it appears some distros have used undocumented extract_synopsis() in
their user tests, and the change is causing their distros to fail
- Added contributors into META file through dzil plugin
perl-Test-Synopsis.spec | 17 +
sources |2 +-
2 files changed, 14 insertions(+), 5 deletions(-)
---
diff --git a/perl-Test-Synopsis.spec b/perl-Test-Synopsis.spec
index 4dfded9..b4b4815 100644
--- a/perl-Test-Synopsis.spec
+++ b/perl-Test-Synopsis.spec
@@ -4,7 +4,7 @@
%global debug_package %{nil}
Name: perl-Test-Synopsis
-Version: 0.08
+Version: 0.10
Release: 1%{?dist}
Summary: Test your SYNOPSIS code
Group: Development/Libraries
@@ -26,7 +26,7 @@ BuildRequires:perl(warnings)
BuildRequires: perl(File::Spec)
BuildRequires: perl(IO::Handle)
BuildRequires: perl(IPC::Open3)
-BuildRequires: perl(Test::Builder) = 0.33
+BuildRequires: perl(Test::Builder) = 0.34
BuildRequires: perl(Test::Builder::Tester)
BuildRequires: perl(Test::More)
# Extra Tests; can't run these when bootstrapping or in EL since many
@@ -90,14 +90,23 @@ rm -rf %{buildroot}
%{_mandir}/man3/Test::Synopsis.3pm*
%changelog
-* Wed Feb 5 2014 Paul Howarth p...@city-fan.org 0.08-1
+* Fri Feb 7 2014 Paul Howarth p...@city-fan.org - 0.10-1
+- Update to 0.10
+ - Fixed prereqs to allow earlier versions of Test-Simple (Issue #9)
+ - Removed POD errors from test .pm's to increase Kwalitee
+ - Reverted the change of renaming extract_synopsis() to _extract_synopsis(),
+as it appears some distros have used undocumented extract_synopsis() in
+their user tests, and the change is causing their distros to fail
+ - Added contributors into META file through dzil plugin
+
+* Wed Feb 5 2014 Paul Howarth p...@city-fan.org - 0.08-1
- Update to 0.08
- Implemented proper handling of __DATA__ tokens
- Removed unwanted warnings issued during tests
- Upped required Test-Simple distro version (fixes Issue #9)
- Minor pod fixes
-* Wed Feb 5 2014 Paul Howarth p...@city-fan.org 0.07-1
+* Wed Feb 5 2014 Paul Howarth p...@city-fan.org - 0.07-1
- Update to 0.07
- Converted to dzil for automation of everything and auto-generation of all
the author/release tests and extra files
diff --git a/sources b/sources
index 450151b..58e17fa 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-54efb466f845da17c3df72c72db45a99 Test-Synopsis-0.08.tar.gz
+9b9f333678d51e32966538b380e3cc41 Test-Synopsis-0.10.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Synopsis] Created tag perl-Test-Synopsis-0.10-1.fc21
The lightweight tag 'perl-Test-Synopsis-0.10-1.fc21' was created pointing to: eec08e2... Update to 0.10 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: f20, anaconda, net install and video out of range ....
On 7 February 2014 09:19, Paul Wouters p...@nohats.ca wrote: Taking out everyone who tries to run fedora or rhel7 using a physical cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III servers with SCSI disks and cirrus cards. In fact, I think you will see it more within the enterprise then outside it. Not really. The enterprise side usually sticks to a maximum 5 year warranty cycle for hardware because it works better from everything from insurance, PCI certs, and taxes and other filings.. If they have old stuff it is running software which can't be run on anything but the OS it has currently. So your old P-III box is going to be running RHEL-2.1/RHL-7.3 because whatever business app it has only runs or is only supported on that. Businesses that are relying on very old hardware tend to fall into three camps. 1) They are big budget places that can pay Dell, HP, IBM more money in yearly warranty costs than a new server would cost. 2) Small places where they are getting by day by day and have better things to do than pay for an Enterprise OS because they would like to pay themselves. 3) Individual consultants who love to keep old stuff around because they never know when they might need it (usually at 4 am when some new client calls and says We found that our accounting system relies on this old Gateway computer with some sort of thick cables sticking out of it to something making a lot of metalic noise at the moment. Number 1 will pay Red Hat, SUSE, Dell, IBM etc to support Red Hat Enterprise 2.1 til the heat death of the universe (ie they go bankrupt the next fiscal crisis). Number 2 will use whatever was on the box until they can't get parts for it... Number 3 won't want to put something new on it because if they need to support Red Hat Linux 4.2, they will need a working copy of it on the hardware of the time. [If they do it is to prove to their customer that putting RHEL-7 on a 10 year old computer is a bad idea and then bill them for the replacement computer.] Only two of those camps will pay for licenses (the consultants will do so as they need it and as long as they have a customer they can bill it to). None of those camps will want to put a new enterprise OS on old hardware. Now for the non enterprise market, there are many different areas that will want to put new software on old hardware. However they either can do it themselves and work through various problems, or they see it is going to cost them more time than it is worth and go back to old stuff. -- Stephen J Smoogen. -- 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: Auto-expiring bugs are getting absurd
From: mat...@fedoraproject.org if someone has a clever way to automatically identify the most important candidates from the thousands, that would be very useful. What about having the ability to vote for bugs? I've seen it used effectively and in other cases, not so much. Maybe this could be as simple as the number of non-default CCs for a BZ. I know some bugs I've been on have CCs added quite regularly. Surely that has to indicate the interest, if not importance. -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 656 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 147 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 111 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 86 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 76 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0132/graphviz-2.12-10.el5 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0400/mediawiki119-1.19.11-2.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0418/libyaml-0.1.2-5.el5 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0410/zarafa-7.1.8-1.el5,php53-mapi-7.1.8-1.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0433/puppet-2.7.25-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0471/lighttpd-1.4.34-1.el5.1 The following builds have been pushed to Fedora EPEL 5 updates-testing nfdump-1.6.11-1.el5 Details about builds: nfdump-1.6.11-1.el5 (FEDORA-EPEL-2014-0473) NetFlow collecting and processing tools Update Information: Nfdump initial RPM release References: [ 1 ] Bug #1055126 - Review Request: nfdump - NetFlow collecting and processing tools https://bugzilla.redhat.com/show_bug.cgi?id=1055126 ___ epel-devel mailing list epel-de...@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 656 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 86 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 50 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0378/quassel-0.9.2-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0398/socat-1.7.2.3-1.el6 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0395/libpng10-1.0.60-6.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0401/libyaml-0.1.3-4.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0409/zarafa-7.1.8-1.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0429/mediawiki119-1.19.11-2.el6 4 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0426/tpp-1.3.1-17.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0466/python-gnupg-0.3.6-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0465/lighttpd-1.4.34-1.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing 2ping-2.0-2.el6 gambit-c-4.7.2-1.el6 libdwarf-20140131-2.el6 lynis-1.4.0-1.el6 nfdump-1.6.11-1.el6 python-django-addons-0.6.6-1.el6 python-docker-py-0.2.3-6.el6 qt5-qtbase-5.2.1-2.el6 qt5-qtconnectivity-5.2.1-1.el6 qt5-qtdeclarative-5.2.1-1.el6 qt5-qtdoc-5.2.1-1.el6 qt5-qtgraphicaleffects-5.2.1-1.el6 qt5-qtimageformats-5.2.1-1.el6 qt5-qtlocation-5.2.1-1.el6 qt5-qtmultimedia-5.2.1-1.el6 qt5-qtquick1-5.2.1-1.el6 qt5-qtquickcontrols-5.2.1-1.el6 qt5-qtscript-5.2.1-1.el6 qt5-qtsensors-5.2.1-1.el6 qt5-qtserialport-5.2.1-1.el6 qt5-qtsvg-5.2.1-1.el6 qt5-qttools-5.2.1-1.el6 qt5-qttranslations-5.2.1-1.el6 qt5-qtwebkit-5.2.1-1.el6 qt5-qtx11extras-5.2.1-1.el6 qt5-qtxmlpatterns-5.2.1-1.el6 Details about builds: 2ping-2.0-2.el6 (FEDORA-EPEL-2014-0480) Bi-directional ping utility Update Information: 2ping on EPEL6. Nice utility for SYN detection and analysis. References: [ 1 ] Bug #985640 - Review Request: 2ping - Bi-directional ping utility https://bugzilla.redhat.com/show_bug.cgi?id=985640 gambit-c-4.7.2-1.el6 (FEDORA-EPEL-2014-0476) Scheme programming system Update Information: - Update to 4.7.2, see https://github.com/feeley/gambit/commits for changes - now buildable on ARM64 ChangeLog: * Fri Feb 7 2014 Michel Salim sali...@fedoraproject.org - 4.7.2-1 - Update to 4.7.2 * Tue Nov 5 2013 Kyle McMartin k...@fedoraproject.org - Fix FTBFS because of dirname macro, use _dirname instead. References: [ 1 ] Bug #913976 - gambit-c-4.7.2 is available https://bugzilla.redhat.com/show_bug.cgi?id=913976 [ 2 ] Bug #925382 - gambit-c: Does not support aarch64 in f19 and rawhide https://bugzilla.redhat.com/show_bug.cgi?id=925382 libdwarf-20140131-2.el6 (FEDORA-EPEL-2014-0477) Library to access the DWARF Debugging file format Update Information: - Update to 20140131 upstream release - Link libdwarf.so with libelf ChangeLog: * Tue Feb 4 2014 Tom Hughes t...@compton.nu - 20140131-2 - Link libdwarf.so with libelf * Sun Feb 2 2014 Tom Hughes t...@compton.nu - 20140131-1 - Update to 20140131 upstream release * Tue Jan 7 2014 Tom Hughes t...@compton.nu - 20130729-2 - Update upstream URLs to point at new site lynis-1.4.0-1.el6 (FEDORA-EPEL-2014-0478) Security and system auditing tool Update Information: * 1.4.0 (2014-01-29) Changes: - Removed some warnings, to prevent double messages - Extended
Re: change Selinux context in %post?
Ok, after sleeping on it, I have a question. Do I really need a full blown policy? I'm not creating anything new here. I'm just applying the existing context applied to /var/lib/mongod to /var/lib/unifi/data, so can I just use semanage from %postrans? 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
[perl-Module-Find/epel7] (3 commits) ...Update to 0.12
Summary of changes: ce0f02f... Perl 5.18 rebuild (*) 0088e3f... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) 4a51b3e... Update to 0.12 (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
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-de...@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-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: mojomojo
mojomojo has broken dependencies in the rawhide tree: On x86_64: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On i386: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) On armhfp: mojomojo-1.10-1.fc20.noarch requires perl(HTML::FormFu::Element::reCAPTCHA) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-qpid_proton
perl-qpid_proton has broken dependencies in the rawhide tree: On x86_64: perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.x86_64 requires perl(qpid::proton::ExceptionHandling) On i386: perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.i686 requires perl(qpid::proton::ExceptionHandling) On armhfp: perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid_proton) perl-qpid_proton-0.6-1.fc21.armv7hl requires perl(qpid::proton::ExceptionHandling) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Auto-expiring bugs are getting absurd
On Fri, 2014-02-07 at 08:48 -0600, Michael Catanzaro wrote: On Thu, 2014-02-06 at 23:54 -0800, Adam Williamson wrote: On Thu, 2014-02-06 at 13:21 +0100, Michael Schwendt wrote: Where is the human to notice comments after EOL and act accordingly? In practice, GNOME maintainers have hundreds of bugs apiece and so rarely respond to individual bug reports, even simple requests to close or reopen a bug. Also many GNOME bugs are assigned to the Red Hat email address of somebody who I believe no longer works at Red Hat There's supposed to be a process for this, I've seen it happen multiple times when someone leaves. Their manager is expected to have their BZ account closed and the bugs re-assigned, I believe. So: if you know who that person's manager was... -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: f20, anaconda, net install and video out of range ....
On Fri, 2014-02-07 at 11:19 -0500, Paul Wouters wrote: Taking out everyone who tries to run fedora or rhel7 using a physical cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III servers with SCSI disks and cirrus cards. In fact, I think you will see it more within the enterprise then outside it. Hah! That's the laugh I needed to kick off my weekend. Cirrus hasn't made PC graphics cards since 1996, according to wikipedia. They haven't been in the video business at all since like 2005. RHEL5 was 2006ish, and I've _never_ heard of any customer running RHEL5+ on a physical cirrus (and I would be the guy in the position to hear about it). Also, nobody running that configuration would be running it on RHEL7, since if the beta's any indication there's no 32-bit kernel. So no, I reject your premises, logic, and conclusions. If you want to maintain the cirrus driver I'm pretty sure it's already orphaned, but it is quite literally not worth my time to work on physical cirrus support nine to eighteen years after the manufacturer left the industry. You can call that lazy if you like, I can't really stop you, but I'm not losing any sleep over it. - ajax -- 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: f20, anaconda, net install and video out of range ....
On Fri, Feb 07, 2014 at 11:19:38AM -0500, Paul Wouters wrote: On Thu, 6 Feb 2014, Adam Williamson wrote: painstakingly hand-weeding something like M*a's ldetect-lst you can get some minor benefits, like doing this kind of distinction where we want to load the native driver for a real card but not qemu's emulated cirrus. You are telling me it is hard to detect the real physical card versus the emulated card? Come on! You can even make that decision by looking at the cpu type. If your cpu is QEMU Virtual CPU, how about using the virtual cirrus driver Oh, that's not difficult - it'd be possible to make the cirrus driver bail on virtualised hardware (easy to detect, just check whether there's a KMS driver bound). But that would still require someone to care about maintaining the cirrus driver, which nobody does. Taking out everyone who tries to run fedora or rhel7 using a physical cirrus card IMHO is just sloppy and lazy. Yes, people still run P-III servers with SCSI disks and cirrus cards. In fact, I think you will see it more within the enterprise then outside it. As Adam points out, nobody's running RHEL7 on a physical cirrus card. However, we'd still expect the vesa driver to work, and the fact that it doesn't is a bug[1]. Nobody ever added exa support to Cirrus, so it's not like you'd see any meaningful difference in performance. [1] I mean plausibly it's a bug in this particular Cirrus video BIOS, but it'd be nice to actually figure that out. -- Matthew Garrett | mj...@srcf.ucam.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: Auto-expiring bugs are getting absurd
On Thu, 06 Feb, 2014 at 12:40:26 GMT, Matthew Miller wrote: I think it's acknowledgement that we don't have resources to fix all of the crap. But I'd like if we could better identify the important cases where we actually *should* make sure issues are addressed, while finding the right balance between maintainer and user/reported burdens. Bugs with patches posted should probably get bumped up to the top since patches imply some work on the part of the reporter (or some other kind soul). --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1059002] On F19, perl's IO::Socket::SSL has problems verifying server's certificate (but works on F20)
https://bugzilla.redhat.com/show_bug.cgi?id=1059002 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-IO-Socket-SSL-1.88-2.f ||c19 Resolution|--- |ERRATA Last Closed||2014-02-08 00:04:57 --- Comment #5 from Fedora Update System upda...@fedoraproject.org --- perl-IO-Socket-SSL-1.88-2.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k6Yg5t4GNha=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] Please review: Ticket #47692 single valued attribute replicated ADD does not work
https://fedorahosted.org/389/attachment/ticket/47692/0001-Ticket-47692-single-valued-attribute-replicated-ADD-.patch -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
[389-devel] Please review: [389 Project] #47693: Environment variables are not passed when DS is started via service
https://fedorahosted.org/389/ticket/47693 https://fedorahosted.org/389/attachment/ticket/47693/0001-Ticket-47693-Environment-variables-are-not-passed-wh.patch Description: Environment variables (except TERM and LANG) are ignored if a program is started via service. If it is started with systemctl, it takes this COMMAND and the values are correctly passed to the server. systemctl set-environment SLAPD_MXFAST=0 MALLOC_TRIM_THRESHOLD_=4096 To control them explicitly and to provide the same instructions to the service and systemctl, it'd be good to have some variables (SLAPD_MXFAST, MALLOC_TRIM_THRESHOLD_ and MALLOC_MMAP_THRESHOLD_ in this patch) configurable. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
