EPEL epel beta report: 20140110 changes
Compose started at Fri Jan 10 00:36:50 UTC 2014 New package: python-BeautifulSoup-3.2.1-7.el7 HTML/XML parser for quick-turnaround applications like screen-scraping New package: python-backlash-0.0.1-0.3.a2.el7 Standalone WebOb port of the Werkzeug Debugger New package: python-chameleon-2.11-2.el7 XML-based template compiler New package: python-cherrypy-3.2.2-4.el7 Pythonic, object-oriented web development framework New package: python-crank-0.6.4-1.el7 Generalization of dispatch mechanism for use across frameworks New package: python-crypto-2.6.1-1.el7 Cryptography library for Python New package: python-decoratortools-1.8-6.el7 Use class and function decorators -- even in Python 2.3 New package: python-formencode-1.2.6-1.el7 HTML form validation, generation, and convertion package New package: python-mock-0.8.0-6.el7 A Python Mocking and Patching Library for Testing New package: python-paste-deploy-1.5.0-10.el7 Load, configure, and compose WSGI applications and servers New package: python-paste-script-1.7.5-6.el7 A pluggable command-line frontend New package: python-peak-rules-0.5a1.dev-16.a1.dev.20100803svn2646.el7 Generic functions and business rules support systems New package: python-peak-util-addons-0.7-6.el7 Dynamically extend other objects with AddOns New package: python-peak-util-assembler-0.6-6.20100803svn2646.el7 Generate Python code objects by assembling bytecode New package: python-peak-util-symbols-1.0-9.el7 Simple symbol type, useful for enumerations or sentinels New package: python-pydns-2.3.6-1.el7 Python module for DNS (Domain Name Service) New package: python-repoze-lru-0.4-3.el7 A tiny LRU cache implementation and decorator New package: python-repoze-who-friendlyform-1.0.8-5.el7 Collection of repoze.who friendly form plugins New package: python-repoze-who-plugins-sa-1.0.1-3.el7 The repoze.who SQLAlchemy plugin New package: python-simplegeneric-0.8-7.el7 Simple generic functions (similar to Python's own len(), pickle.dump(), etc.) New package: python-sqlalchemy-0.8.4-1.el7 Modular and flexible ORM library for python New package: python-sqlobject-1.2.2-3.el7 SQLObject Object-Relational Manager, aka database wrapper New package: python-strainer-0.1.4-4.el7 Tools to allow developers to cleanup web serialization objects New package: python-turbojson-1.3.2-5.el7 Python template plugin that supports json New package: python-webflash-0.1-0.8.a9.el7 Portable flash messages for WSGI apps Summary: Added Packages: 25 Removed Packages: 0 Modified Packages: 0 ___ 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 628 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 142 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11274/ssmtp-2.61-21.el6 84 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11865/quassel-0.9.1-1.el6 57 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12079/bip-0.8.9-1.el6 21 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12427/seamonkey-2.21-3.esr2.el6 6 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0026/x2goserver-4.0.1.10-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0110/drupal7-entity-1.3-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0105/strongswan-5.1.1-4.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing docker-io-0.7.4-1.el6 drupal7-entity-1.3-1.el6 drupal7-language_cookie-1.8-1.el6 globus-gram-job-manager-condor-1.4-7.el6 globus-gram-job-manager-fork-1.5-8.el6 globus-gram-job-manager-lsf-1.2-2.el6 globus-gram-job-manager-pbs-1.6-7.el6 globus-gram-job-manager-sge-1.7-2.el6 globus-gram-job-manager-slurm-1.2-3.el6 globus-scheduler-event-generator-4.7-8.el6 milter-greylist-4.5.7-1.el6 msgpack-0.5.8-1.el6 nodejs-mongodb-1.3.19-3.el6 puppet-2.7.25-1.el6 pyhoca-cli-0.4.0.2-1.el6 pyhoca-gui-0.4.0.9-1.el6 python-chai-0.4.7-1.el6 python-docker-py-0.2.3-5.el6 python-pyarabic-0.4-4.el6 python-x2go-0.4.0.9-1.el6 strongswan-5.1.1-4.el6 trac-fedmsg-plugin-0.3.0-1.el6 unhide-20130526-1.el6 Details about builds: docker-io-0.7.4-1.el6 (FEDORA-EPEL-2014-0101) Automates deployment of containerized applications Update Information: upstream version bump to 0.7.4 (BZ 1049793) udev rules typo fixed (BZ 1048775) missed commit value in release 1, updated now ChangeLog: * Thu Jan 9 2014 Lokesh Mandvekar l...@redhat.com - 0.7.4-1 - upstream version bump to 0.7.4 (BZ #1049793) - udev rules file from upstream contrib - unit file firewalld not used, description changes * Mon Jan 6 2014 Lokesh Mandvekar l...@redhat.com - 0.7.3-3 - udev rules typo fixed (BZ 1048775) * Sat Jan 4 2014 Lokesh Mandvekar l...@redhat.com - 0.7.3-2 - missed commit value in release 1, updated now - upstream release monitoring (BZ 1048441) * Sat Jan 4 2014 Lokesh Mandvekar l...@redhat.com - 0.7.3-1 - upstream release bump to v0.7.3 References: [ 1 ] Bug #1049793 - docker-io-0.7.4 is available https://bugzilla.redhat.com/show_bug.cgi?id=1049793 [ 2 ] Bug #1048775 - invalid key/value pair in /etc/udev/rules.d/80-docker.rules https://bugzilla.redhat.com/show_bug.cgi?id=1048775 [ 3 ] Bug #1048441 - docker-io-0.7.3 is available https://bugzilla.redhat.com/show_bug.cgi?id=1048441 drupal7-entity-1.3-1.el6 (FEDORA-EPEL-2014-0110) Extends the entity API to provide a unified way to deal with entities Update Information: Updated to 1.3 1.3 * Release notes: https://drupal.org/node/2169589 * SA-CONTRIB-2014-001: https://drupal.org/node/2169595 * CVE-2014-1398, CVE-2014-1399, CVE-2014-1400 1.2 * Release notes: https://drupal.org/node/2065197 * SA-CONTRIB-2013-068: https://drupal.org/node/2065207 1.1 * Release notes: https://drupal.org/node/1983440 ChangeLog: * Thu Jan 9 2014 Shawn Iwinski shawn.iwin...@gmail.com - 1.3-1 - Updated to 1.3 (release notes: https://drupal.org/node/2169589) (BZ #1050853) - CVE-2014-1398, CVE-2014-1399, CVE-2014-1400 (BZ #1050802, 1050803, 1050804) - SA-CONTRIB-2014-001 (https://drupal.org/node/2169595) - Spec cleanup References: [ 1 ] Bug #1050802 - CVE-2014-1398 CVE-2014-1399 CVE-2014-1400 drupal7-entity: multiple access bypass vulnerabilities https://bugzilla.redhat.com/show_bug.cgi?id=1050802 drupal7-language_cookie-1.8-1.el6 (FEDORA-EPEL-2014-0099) Allows usage of cookies to remember the user's last language Update Information: Updated to 1.8 * Release notes:
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 628 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 142 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11276/ssmtp-2.61-21.el5 118 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11560/fail2ban-0.8.10-4.el5 82 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 57 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12091/bip-0.8.9-1.el5 47 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12159/389-ds-base-1.2.11.25-1.el5 47 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-12169/gc-7.1-6.el5 2 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0075/graphviz-2.12-9.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0112/drupal7-entity-1.3-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing drupal7-entity-1.3-1.el5 drupal7-language_cookie-1.8-1.el5 globus-gram-job-manager-condor-1.4-7.el5 globus-gram-job-manager-fork-1.5-8.el5 globus-gram-job-manager-lsf-1.2-2.el5 globus-gram-job-manager-pbs-1.6-7.el5 globus-gram-job-manager-sge-1.7-2.el5 globus-gram-job-manager-slurm-1.2-3.el5 globus-scheduler-event-generator-4.7-8.el5 Details about builds: drupal7-entity-1.3-1.el5 (FEDORA-EPEL-2014-0112) Extends the entity API to provide a unified way to deal with entities Update Information: Updated to 1.3 1.3 * Release notes: https://drupal.org/node/2169589 * SA-CONTRIB-2014-001: https://drupal.org/node/2169595 * CVE-2014-1398, CVE-2014-1399, CVE-2014-1400 1.2 * Release notes: https://drupal.org/node/2065197 * SA-CONTRIB-2013-068: https://drupal.org/node/2065207 1.1 * Release notes: https://drupal.org/node/1983440 ChangeLog: * Thu Jan 9 2014 Shawn Iwinski shawn.iwin...@gmail.com - 1.3-1 - Updated to 1.3 (release notes: https://drupal.org/node/2169589) (BZ #1050853) - CVE-2014-1398, CVE-2014-1399, CVE-2014-1400 (BZ #1050802, 1050803, 1050804) - SA-CONTRIB-2014-001 (https://drupal.org/node/2169595) - Spec cleanup * Fri Aug 16 2013 Peter Borsa peter.bo...@gmail.com - 1.2-1 - Update to upstream 1.2 release for security and bug fixes - Upstream changelog for this release is available at https://drupal.org/node/2065197 - SA-CONTRIB-2013-068 https://drupal.org/node/2065207 * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.1-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Wed Jun 12 2013 Peter Borsa peter.bo...@gmail.com - 1.1-1 - Update to upstream 1.1 release for bug fixes - Upstream changelog for this release is avalble at https://drupal.org/node/1983440 References: [ 1 ] Bug #1050802 - CVE-2014-1398 CVE-2014-1399 CVE-2014-1400 drupal7-entity: multiple access bypass vulnerabilities https://bugzilla.redhat.com/show_bug.cgi?id=1050802 drupal7-language_cookie-1.8-1.el5 (FEDORA-EPEL-2014-0107) Allows usage of cookies to remember the user's last language Update Information: Updated to 1.8 * Release notes: https://drupal.org/node/2150363 ChangeLog: * Thu Jan 9 2014 Shawn Iwinski shawn.iwin...@gmail.com 1.8-1 - Updated to 1.8 (release notes: https://drupal.org/node/2150363) (BZ #1039692) References: [ 1 ] Bug #1039692 - drupal7-language_cookie-1.8 is available https://bugzilla.redhat.com/show_bug.cgi?id=1039692 globus-gram-job-manager-condor-1.4-7.el5 (FEDORA-EPEL-2014-0104) Globus Toolkit - Condor Job Manager Support Update Information: Make GRAM SEG logfile locations consistent. ChangeLog: * Thu Jan 9 2014 Mattias Ellert mattias.ell...@fysast.uu.se - 1.4-7 - Remove unused configure option * Sat Aug 3 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.4-6 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild * Sun Jul 28 2013 Mattias Ellert mattias.ell...@fysast.uu.se -
Re: Unannounced soname bump: satyr (libsatyr.so.2 - libsatyr.so.3) - affects libreport and abrt
I am sorry for the inconvenience. We usually rebuild entire ABRT stack (satyr/libreport/abrt) at once , however, I'm not able to build abrt for Rawhide because of some strange auto* error. The build works on my Rawhide VM but the koji build fails. I will be more careful next time. Regards, Jakub - Original Message - From: Adam Williamson awill...@redhat.com To: devel@lists.fedoraproject.org Cc: mmil...@redhat.com, jfi...@redhat.com Sent: Thursday, January 9, 2014 3:22:18 AM Subject: Unannounced soname bump: satyr (libsatyr.so.2 - libsatyr.so.3) - affects libreport and abrt The 'satyr' package in Rawhide was bumped from 0.12 to 0.13 yesterday. This bumps the library's soname from libsatyr.so.2 to libsatyr.so.3 . This was not announced on devel@, as it is supposed to be (or the person doing the bump must immediately handle rebuilds of all dependent packages). abrt and libreport both depend on libsatyr.so.2. libreport has been rebuilt, but abrt has not. I have tried rebuilding abrt (bumping to 2.1.11 - another packaging mistake here is that 2.1.11 has been built for Fedora 20 before Rawhide, breaking the upgrade path), and it compiles fine, but the test suite fails: http://koji.fedoraproject.org/koji/getfile?taskID=6377189name=build.logoffset=-4000 ## --- ## ## abrt 2.1.11 test suite. ## ## --- ## kernel oops parser 1: koops_extract_version FAILED (koops-parser.at:5) 2: koops_tainted_short FAILED (koops-parser.at:51) 3: koops_hash_improve FAILED (koops-parser.at:121) 4: koops_parser_sanity FAILED (koops-parser.at:167) python hook 5: pyhook_zerodiv ok 6: pyhook_indent ok ignored problems 7: ignored_problems_allFAILED (ignored_problems.at:5) Until someone who can fix abrt does so, Rawhide users will not be able to update satyr (and hence libreport) and nightly live composes will all fail, as they all include abrt. Once again, folks, please co-ordinate your soname bumps. -- 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: Non-responsive easytag package maintainer
On 2014-01-08 13:16, Kevin Fenzi ke...@scrye.com wrote: On Wed, 1 Jan 2014 18:09:32 +0400 Peter Lemenkov lemen...@gmail.com wrote: Matthias seems to stop his participation in Fedora ~1 year ago: http://koji.fedoraproject.org/koji/tasks?owner=thiasstate=all Dave, I think you should be granted a primary maintainer status for EasyTAG. I mailed Matthias today and got a reply in about 30min. :) Anyhow, he has been very busy with life and hasn't had time to keep up on things. I suggested he add co-maintainers at least that could take over his packages while he's busy and he agreed. Hopefully he will also chime in here. In the mean time, you could request acls for the package and drop him an email asking for him to approve them. Thanks! I had already requested commit privileges for a couple of branches a while ago, but requested another one this morning and sent Matthias an email. He quickly approved the ACL changes, so I am now co-maintainer of master, f19 and f20 branches. Matthias mentioned to me that he will send an email to this list, asking for maintainers or co-maintainers for many of his packages, which should help a lot. -- http://amigadave.com/ signature.asc Description: 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
Livecd-creator is disabling selinux
Dear guys and ladies, So it seems like livecd-creator is silently disabling selinux. Proof: vim $(which livecd-creator) ; line 150 Fact, that it's re-enabled afterwards doesn't ease silent disablement of security feature. I'd love to know the reason and if it's possible to do something about it. Cheers, - maros N.b.: i'm sorry if this is repost -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Fedora 20 release day FedUp bug: post-mortem
On 09.01.2014 08:34, Vratislav Podzimek wrote: I really hope we will, that's how big steps in innovation happen in this fast-moving world. And we don't want to be limping behind, do we? http://youtu.be/so9DBHCo64Q poma -- 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: Grub installation. First potential Fedora killer
On 01/02/2014 11:32 PM, Jean François Martinez wrote: I have a nice booter setup and a nice _main_ Linux installation. Last thing I would want is a distribution I am _testing_, that is Fedora 20 forces on me it will be my main installation and forces me to choose between installing Grub on the MBR or not at all. In addition it didn't detect my other Linux installation so at first boot I was only able to choose between Fedora 20 and Fedora 20. Fortunately running grub-install fixed it (ie this time my other installations were detected). Sort of. First of all because Fedora 20, ie a ditribution I was _testing_ was now the default and second of all because every time I upgrade the kernel of my _main_ distribution I am supposed to reboot on F20 and run grub-install. Great. Nothing I can't fix but your average Ubuntu or Suse user will just cancel installation as soon he notices F20 is going to force itself on his MBR. And if the road is a one way one between Fedora and Ubintu then it is doomed. That's the reason we came up with http://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ and even have a patch for grub2 http://pkgs.fedoraproject.org/cgit/grub2.git/tree/0460-blscfg-add-blscfg-module-to-parse-Boot-Loader-Specif.patch If all bootloaders would follow the spec, nothing has to be configured manually and would just use the dropin directories. -- 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: Livecd-creator is disabling selinux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/09/2014 05:32 AM, Maros Zatko wrote: Dear guys and ladies, So it seems like livecd-creator is silently disabling selinux. Proof: vim $(which livecd-creator) ; line 150 Fact, that it's re-enabled afterwards doesn't ease silent disablement of security feature. I'd love to know the reason and if it's possible to do something about it. Cheers, - maros N.b.: i'm sorry if this is repost Please open a bugzilla on this, and CC me on it. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLOr3QACgkQrlYvE4MpobN1mwCg3hwxswlI5kvbrJOb0qYzR+23 GnYAoKYoOf+pho+PkL6B6JWiZmN8V5KK =VP4w -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: nod Just have yum drop a config file in there that protects the kernel rather than protecting the kernel if some other package chooses to protect something else. The magic don't delete the running kernel can't be done with just a config file. Something has to detect which kernel version is running and match it to an RPM, and then protect just that version of multiple installed kernel RPMs. I supposed you could do it external to yum/dnf with a boot-time script that rewrites a config file to protect kernel-$(uname -r), but that may not always work (it would have to handle things like kernel-PAE and such). -- Chris Adams li...@cmadams.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
dnf-0.4.11
Hello, New DNF release is out. See the blog [1], the release notes [2] and the F20 update [3]. Rawhide build went smooth this time too! Ales [1] http://dnf.baseurl.org/2014/01/09/dnf-0-4-11-released/ [2] http://akozumpl.github.io/dnf/release_notes.html#id22 [3] https://admin.fedoraproject.org/updates/dnf-0.4.11-1.fc20 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Jan 7, 2014 4:53 AM, Frank Murphy frankl...@gmail.com wrote: On Thu, 02 Jan 2014 16:28:59 +0100 Reindl Harald h.rei...@thelounge.net wrote: look like it starts to happen again: a replacement which is not ready https://bugzilla.redhat.com/show_bug.cgi?id=1049310 It seems the majority want the current dnf default [1] to be kept Those who want to keep running kernel may need to speak up [2] [1] http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel [2] https://bugzilla.redhat.com/show_bug.cgi?id=1049310 After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess. -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On 01/09/2014 03:56 PM, Toshio Kuratomi wrote: On Jan 7, 2014 4:53 AM, Frank Murphy frankl...@gmail.com mailto:frankl...@gmail.com wrote: On Thu, 02 Jan 2014 16:28:59 +0100 Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: look like it starts to happen again: a replacement which is not ready https://bugzilla.redhat.com/show_bug.cgi?id=1049310 It seems the majority want the current dnf default [1] to be kept Those who want to keep running kernel may need to speak up [2] [1] http://akozumpl.github.io/dnf/cli_vs_yum.html#dnf-erase-kernel-deletes-all-packages-called-kernel [2] https://bugzilla.redhat.com/show_bug.cgi?id=1049310 After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess. And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things. Thanks, Jirka -Toshio -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Jan 9, 2014 6:26 AM, Chris Adams li...@cmadams.net wrote: Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: nod Just have yum drop a config file in there that protects the kernel rather than protecting the kernel if some other package chooses to protect something else. The magic don't delete the running kernel can't be done with just a config file. Something has to detect which kernel version is running and match it to an RPM, and then protect just that version of multiple installed kernel RPMs. Can't the meaning of a package name in the config file simply mean: make sure one of these packages is always installed? That won't protect the running kernel but it will protect a kernel (probably the latest installed). That would seem to address hreindl's use case of wanting to test on multiple systems and when satisfied that things are working cleanup all older packages. That would still be a difference from the current yum code but less than not having any protection at all and would be more generic. -Toshio I supposed you could do it external to yum/dnf with a boot-time script that rewrites a config file to protect kernel-$(uname -r), but that may not always work (it would have to handle things like kernel-PAE and such). -- Chris Adams li...@cmadams.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 -- 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: Unannounced soname bump: satyr (libsatyr.so.2 - libsatyr.so.3) - affects libreport and abrt
This appears to have also broken Fedora 19 updates-testing, which is even less acceptable than breaking rawhide. -- Running transaction check --- Package abrt.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: satyr = 0.13 for package: abrt-2.1.11-1.fc19.x86_64 -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-2.1.11-1.fc19.x86_64 --- Package abrt-addon-ccpp.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-ccpp-2.1.11-1.fc19.x86_64 --- Package abrt-addon-kerneloops.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-kerneloops-2.1.11-1.fc19.x86_64 --- Package abrt-addon-pstoreoops.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-pstoreoops-2.1.11-1.fc19.x86_64 --- Package abrt-addon-xorg.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-xorg-2.1.11-1.fc19.x86_64 --- Package abrt-dbus.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-dbus-2.1.11-1.fc19.x86_64 --- Package abrt-gui.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-gui-2.1.11-1.fc19.x86_64 --- Package abrt-libs.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-libs-2.1.11-1.fc19.x86_64 --- Package abrt-plugin-bodhi.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-plugin-bodhi-2.1.11-1.fc19.x86_64 --- Package abrt-python.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-python-2.1.11-1.fc19.x86_64 --- Package abrt-retrace-client.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-retrace-client-2.1.11-1.fc19.x86_64 --- Package libreport.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: satyr = 0.13 for package: libreport-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-bugzilla.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-bugzilla-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-kerneloops.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-kerneloops-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-reportuploader.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-reportuploader-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-ureport.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-ureport-2.1.11-1.fc19.x86_64 --- Package libreport-web.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-web-2.1.11-1.fc19.x86_64 --- Package python-augeas.noarch 0:0.4.1-3.fc19 will be installed -- Finished Dependency Resolution Error: Package: abrt-addon-xorg-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-plugin-bodhi-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-addon-kerneloops-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-retrace-client-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-python-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-gui-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: libreport-plugin-ureport-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: libreport-plugin-reportuploader-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-libs-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-dbus-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: libreport-plugin-kerneloops-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libs On Thu, Jan 09, 2014 at 03:00:30AM -0500, Jakub Filak wrote: I am sorry for the inconvenience. We usually rebuild entire ABRT stack (satyr/libreport/abrt) at once , however, I'm not able to build abrt for Rawhide because of some strange auto* error. The build works on my Rawhide VM but the koji build fails. I will be more careful next time. Regards, Jakub - Original Message - From: Adam Williamson awill...@redhat.com To: devel@lists.fedoraproject.org
Re: dnf versus yum
Am 09.01.2014 16:03, schrieb Jiri Moskovcak: https://bugzilla.redhat.com/show_bug.cgi?id=1049310 After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess. And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things. in doubt in case of rewrites support the existing features and start the clean codebase with them in mind 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: dnf versus yum
On 01/09/2014 04:12 PM, Reindl Harald wrote: Am 09.01.2014 16:03, schrieb Jiri Moskovcak: https://bugzilla.redhat.com/show_bug.cgi?id=1049310 After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess. And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things. in doubt in case of rewrites support the existing features and start the clean codebase with them in mind And that is official Fedora (I mean respected by the community) rule or yours? --Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Am 09.01.2014 16:37, schrieb Jiri Moskovcak: On 01/09/2014 04:12 PM, Reindl Harald wrote: Am 09.01.2014 16:03, schrieb Jiri Moskovcak: https://bugzilla.redhat.com/show_bug.cgi?id=1049310 After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess. And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things. in doubt in case of rewrites support the existing features and start the clean codebase with them in mind And that is official Fedora (I mean respected by the community) rule or yours? mine - there is no official one and hardly will ever be that is what a user normally expects: optimize things, add new features but do not demand him to change his workflow with no for the user obvious improvement 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: Unannounced soname bump: satyr (libsatyr.so.2 - libsatyr.so.3) - affects libreport and abrt
Again, I am sorry for the inconvenience and I promise that I'll be more careful in the future. This issue was fixed at 11:27:10 CET (2014-01-09) https://admin.fedoraproject.org/updates/FEDORA-2014-0437/satyr-0.13-1.fc19,abrt-2.1.11-1.fc19,libreport-2.1.11-1.fc19 Regards, Jakub - Original Message - From: Chuck Anderson c...@wpi.edu To: devel@lists.fedoraproject.org Sent: Thursday, January 9, 2014 4:13:14 PM Subject: Re: Unannounced soname bump: satyr (libsatyr.so.2 - libsatyr.so.3) - affects libreport and abrt This appears to have also broken Fedora 19 updates-testing, which is even less acceptable than breaking rawhide. -- Running transaction check --- Package abrt.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: satyr = 0.13 for package: abrt-2.1.11-1.fc19.x86_64 -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-2.1.11-1.fc19.x86_64 --- Package abrt-addon-ccpp.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-ccpp-2.1.11-1.fc19.x86_64 --- Package abrt-addon-kerneloops.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-kerneloops-2.1.11-1.fc19.x86_64 --- Package abrt-addon-pstoreoops.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-pstoreoops-2.1.11-1.fc19.x86_64 --- Package abrt-addon-xorg.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-addon-xorg-2.1.11-1.fc19.x86_64 --- Package abrt-dbus.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-dbus-2.1.11-1.fc19.x86_64 --- Package abrt-gui.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-gui-2.1.11-1.fc19.x86_64 --- Package abrt-libs.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-libs-2.1.11-1.fc19.x86_64 --- Package abrt-plugin-bodhi.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-plugin-bodhi-2.1.11-1.fc19.x86_64 --- Package abrt-python.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-python-2.1.11-1.fc19.x86_64 --- Package abrt-retrace-client.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: abrt-retrace-client-2.1.11-1.fc19.x86_64 --- Package libreport.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: satyr = 0.13 for package: libreport-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-bugzilla.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-bugzilla-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-kerneloops.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-kerneloops-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-reportuploader.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-reportuploader-2.1.11-1.fc19.x86_64 --- Package libreport-plugin-ureport.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-plugin-ureport-2.1.11-1.fc19.x86_64 --- Package libreport-web.x86_64 0:2.1.11-1.fc19 will be an update -- Processing Dependency: libsatyr.so.3()(64bit) for package: libreport-web-2.1.11-1.fc19.x86_64 --- Package python-augeas.noarch 0:0.4.1-3.fc19 will be installed -- Finished Dependency Resolution Error: Package: abrt-addon-xorg-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-plugin-bodhi-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-addon-kerneloops-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-retrace-client-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-python-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-gui-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: libreport-plugin-ureport-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: libreport-plugin-reportuploader-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-libs-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: abrt-dbus-2.1.11-1.fc19.x86_64 (updates-testing) Requires: libsatyr.so.3()(64bit) Error: Package: libreport-plugin-kerneloops-2.1.11-1.fc19.x86_64
Re: dnf versus yum
On Thu, 09 Jan 2014 16:03:06 +0100 Jiri Moskovcak jmosk...@redhat.com wrote: And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things. As we always have I think... If the maintainer holds some position it's up to others to convince them to change their position, hopefully by providing facts and rational arguments. If you can't convince them to your position, next you might try some kind of compromise solution if you can think of one. If they don't change their mind and someone feels this is some issue that affects the entire distribution, they can ask FESCo to look into the matter and mediate or override the maintainer. Note however that FESCo very rarely overrides maintainers wishes. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On 01/09/2014 04:40 PM, Reindl Harald wrote: Am 09.01.2014 16:37, schrieb Jiri Moskovcak: On 01/09/2014 04:12 PM, Reindl Harald wrote: Am 09.01.2014 16:03, schrieb Jiri Moskovcak: https://bugzilla.redhat.com/show_bug.cgi?id=1049310 After asking on the bugzilla it seems that ales would like people who want this change to cc themselves on the bug report. If the cc reaches 40 he'll reconsider. Kinda a strange way of deciding but whatever works for the maintainer I guess. And what would be the right way to decide? And please stay assured that this is not a trolling, I would really like to see some agreement in Fedora on how to decide these kind of things. in doubt in case of rewrites support the existing features and start the clean codebase with them in mind And that is official Fedora (I mean respected by the community) rule or yours? mine - there is no official one and hardly will ever be Well, but there will have to be one, at least when the time comes and dnf will proposed as default. At that point someone (fesco?) will have to evaluate it and vote and either accept it or refuse it. And as I see it, the decision will have to be based on some criteria, so I'm actually asking for this criteria to be revealed now so we can end this thread in piece and get back to work... that is what a user normally expects: optimize things, add new features but do not demand him to change his workflow with no for the user obvious improvement Well, I can use dnf in it's current shape quite fine and it works faster than yum which I take as an improvement, so for me it's ok. So what now? --Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On Thu, 09 Jan 2014 16:56:31 +0100 Jiri Moskovcak jmosk...@redhat.com wrote: Well, I can use dnf in it's current shape quite fine and it works faster than yum which I take as an improvement, so for me it's ok. So what now? --Jirka Then add your voice to the bz to keep it as is. ___ Regards, Frank www.frankly3d.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Rawhide PAPI-5.3 rebase warning
PAPI-5.3.0 came out at the beginning of December 2013 (http://icl.cs.utk.edu/papi/news/news.html?id=331). I would like to rebase Fedora rawhide PAPI to PAPI-5.3.0 January 16, 2014. openmpi build is definitely dependent on papi-devel, but I don't know if there are any other packages dependent on papi. -Will -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
qt(4) header prefix moving to /usr/include/qt4
The KDE SIG is considering moving qt(4)'s default header prefix path from /usr/include to /usr/include/qt4 Primary reasons for doing this is to help minimize conflicts between anything qt5-based. When/if this is implemented, Qt4-based library packages, those that provide -devel subpkgs at least, will (likely) need a mass rebuild. I would likely help do most of the heavy-lifting required to implement that. Comments, objections? -- 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
Packages which need to be retired properly
Once again there are some packages, which haven't been retired completely yet. Check out this Wiki page for the steps that are necessary to get packages retired properly: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Dead in below output means the packages are marked dead.package in dist git, but are still found in the repo(s) because they have not been blocked in koji yet. Blocking for released dists (F20 and older) will not be possible anymore. Undead means the packages are not even marked dead.package. The script that performs these checks does not examine pkgdb state, so it could be that even in pkgdb the packages have not been retired yet either. The script also doesn't know whether there are koji block requests in releng for these packages already. In Rawhide: Dead and all builds obsoleted: -- openshift-origin-cartridge-cron-1.4 obsoleted by: openshift-origin-cartridge-cron openshift-origin-cartridge-diy-0.1 obsoleted by: openshift-origin-cartridge-diy Undead and all builds obsoleted: drupal7-features_plumber obsoleted by: drupal7-features mediawiki-SpecialInterwiki obsoleted by: mediawiki mingw-pthreads obsoleted by: mingw-winpthreads php-channel-symfony2 obsoleted by: php-symfony Only obsolete subpackage(s): lzma ['lzma'] 2 left ruby-gnome2 ['ruby-gtksourceview2', 'ruby-gtksourceview2-devel'] 24 left vdsm ['vdsm-python-cpopen'] 34 left Again, packages listed in the last section (only some subpackages are obsolete) are _okay_. For Fedora 20, there are more packages, which may need to be retired properly: Dead and all builds obsoleted: -- openshift-origin-cartridge-cron-1.4 obsoleted by: openshift-origin-cartridge-cron openshift-origin-cartridge-diy-0.1 obsoleted by: openshift-origin-cartridge-diy python-trml2pdf obsoleted by: python-trml2pdf12 python-webob1.2 obsoleted by: python-webob qt5-qtjsbackend obsoleted by: qt5-qtdeclarative xfce4-icon-theme obsoleted by: rodent-icon-theme Undead and all builds obsoleted: blueman obsoleted by: bluez crtools obsoleted by: criu drupal7-features_plumber obsoleted by: drupal7-features libmatekeyring obsoleted by: mate-desktop mate-keyring obsoleted by: mate-desktop mingw-pthreads obsoleted by: mingw-winpthreads php-channel-symfony2 obsoleted by: php-symfony Only obsolete subpackage(s): lzma ['lzma'] 4 left openscap ['openscap-content'] 15 left ruby-gnome2 ['ruby-gtksourceview2', 'ruby-gtksourceview2-devel', 'ruby-gtksourceview2-devel'] 36 left vdsm ['vdsm-python-cpopen'] 34 left yum-utils ['yum-plugin-security'] 27 left -- http://mschwendt.fedorapeople.org/obscheck-remote.py -- 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: Rawhide PAPI-5.3 rebase warning
On 01/09/2014 10:48 AM, William Cohen wrote: PAPI-5.3.0 came out at the beginning of December 2013 (http://icl.cs.utk.edu/papi/news/news.html?id=331). I would like to rebase Fedora rawhide PAPI to PAPI-5.3.0 January 16, 2014. openmpi build is definitely dependent on papi-devel, but I don't know if there are any other packages dependent on papi. -Will I don't see any other users as well. It would be nice to test a build of openmpi against papi 5.3.0 before pushing it to rawhide just to see. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Unannounced soname bump: satyr (libsatyr.so.2 - libsatyr.so.3) - affects libreport and abrt
On Thu, 2014-01-09 at 10:13 -0500, Chuck Anderson wrote: This appears to have also broken Fedora 19 updates-testing, which is even less acceptable than breaking rawhide. Eh, I'd suggest not. updates-testing is actually explicitly meant as a place to catch this kind of problem, whereas we're trying to keep Rawhide rolling and especially try not to break nightly image generation. At least we can vote broken things in updates-testing down. -- 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: dnf versus yum
On 9 January 2014 15:13, Toshio Kuratomi a.bad...@gmail.com wrote: On Jan 9, 2014 6:26 AM, Chris Adams li...@cmadams.net wrote: Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: nod Just have yum drop a config file in there that protects the kernel rather than protecting the kernel if some other package chooses to protect something else. The magic don't delete the running kernel can't be done with just a config file. Something has to detect which kernel version is running and match it to an RPM, and then protect just that version of multiple installed kernel RPMs. Can't the meaning of a package name in the config file simply mean: make sure one of these packages is always installed? That won't protect the running kernel but it will protect a kernel (probably the latest installed). That would seem to address hreindl's use case of wanting to test on multiple systems and when satisfied that things are working cleanup all older packages. Latest installed is almost exactly not what you want, I've had plenty (where plenty in this case is probably 5) of cases where a kernel update broke something, in quite a few of those cases to a state where the system wouldn't boot. If the most recent one is retained then you've still got a kernel, but not one that will actually run. With current behaviour I can still let my system update until a fix appears because I know it won't remove the good kernel. If updates can remove the running kernel then you have to watch each one carefully. Unless I've misunderstood this thread and this does not apply to automatic updates. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Am 09.01.2014 19:58, schrieb Ian Malone: On 9 January 2014 15:13, Toshio Kuratomi a.bad...@gmail.com wrote: On Jan 9, 2014 6:26 AM, Chris Adams li...@cmadams.net wrote: Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: nod Just have yum drop a config file in there that protects the kernel rather than protecting the kernel if some other package chooses to protect something else. The magic don't delete the running kernel can't be done with just a config file. Something has to detect which kernel version is running and match it to an RPM, and then protect just that version of multiple installed kernel RPMs. Can't the meaning of a package name in the config file simply mean: make sure one of these packages is always installed? That won't protect the running kernel but it will protect a kernel (probably the latest installed). That would seem to address hreindl's use case of wanting to test on multiple systems and when satisfied that things are working cleanup all older packages. Latest installed is almost exactly not what you want, I've had plenty (where plenty in this case is probably 5) of cases where a kernel update broke something, in quite a few of those cases to a state where the system wouldn't boot. If the most recent one is retained then you've still got a kernel, but not one that will actually run. With current behaviour I can still let my system update until a fix appears because I know it won't remove the good kernel. If updates can remove the running kernel then you have to watch each one carefully. Unless I've misunderstood this thread and this does not apply to automatic updates. as thread starter: you have *correctly* understood the intention your example shows once more how important it is that the kernel is treatet special, hence i even did not think about this case while i was often happy about it because after some years the current behavior is somehow self-evident 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: Should /usr/bin/Xorg (still) be setuid-root?
Hi, On 01/09/2014 12:09 AM, Andrew Lutomirski wrote: On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote: /usr/bin/Xorg is, and has been, setuid-root just about forever. I'm wondering whether there's any good reason for it to remain setuid-root. http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This isn't actually the same thing. That proposal suggests running Xorg as a non-root user. I'm proposing dropping the setuid bit on the binary, which will have no effect on the uid of the running server. (Of course, my suggestion will interact w/ that change, since the process that starts Xorg will no longer be root.) I don't think that that will be very useful, it will likely cause more breakage then you think, as various display-managers may already start Xorg inside the user session, at which point the suid bit is needed, and as you already said it will break xinit and friends. Besides that almost every Fedora system already has a copy of the X server running as root ready to be exploited. The attack service of X is not its cmdline or attacks through environment settings (2 vectors your suggestion would close), but rather the gargantuan API it exposes over the X protocol itself. It may be that XorgWithoutRootRights will clear the setuid bit as well, though. Hopefully, either clear it completely or drop root rights very early on on startup. Regards, Hans -- 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: Rawhide PAPI-5.3 rebase warning
On 01/09/2014 01:29 PM, Orion Poplawski wrote: On 01/09/2014 10:48 AM, William Cohen wrote: PAPI-5.3.0 came out at the beginning of December 2013 (http://icl.cs.utk.edu/papi/news/news.html?id=331). I would like to rebase Fedora rawhide PAPI to PAPI-5.3.0 January 16, 2014. openmpi build is definitely dependent on papi-devel, but I don't know if there are any other packages dependent on papi. -Will I don't see any other users as well. It would be nice to test a build of openmpi against papi 5.3.0 before pushing it to rawhide just to see. Hi, There is a papi-5.3.0-1 scratch build in koji at: http://koji.fedoraproject.org/koji/taskinfo?taskID=6380410 Please give that a try for openmpi build and let me know if whether it works. -Will -- 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: Sub-package dropped upstream
On Thu, 9 Jan 2014 12:08:49 -0800, Jorge Gallegos wrote: Hi, I maintain the uwsgi package for fedora, which optionally builds a bunch of modules to integrate with several other languages. One of the plugins got recently removed upstream but it hasn't got any replacements yet (see the top of http://uwsgi-docs.readthedocs.org/en/latest/Erlang.html) Currently f19 and f20 have 1.9.19 available, and I would like to update to 1.9.21 but that would mean I have to deprecate the existing package uwsgi-plugin-erlang. Is this the correct approach? adding an obsoletes tag in the spec for uwsgi-plugin-erlang 1.9.20 ? That would be the only way to withdraw the package from users' installations, especially if not obsoleting it would result in broken dependencies. https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages Depending on how popular the package might be, such breakage could annoy users. Tangential question, do we have statistics of how many times this (or any other) package has been downloaded? Hardly feasible, given that every mirror server would need to count downloads and submit the results to the Fedora Project, and then one could still not conclude safely whether a package has been installed actually and is still in use (or has been downloaded/mirrored only). -- 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: Should /usr/bin/Xorg (still) be setuid-root?
On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/09/2014 12:09 AM, Andrew Lutomirski wrote: On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote: /usr/bin/Xorg is, and has been, setuid-root just about forever. I'm wondering whether there's any good reason for it to remain setuid-root. http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This isn't actually the same thing. That proposal suggests running Xorg as a non-root user. I'm proposing dropping the setuid bit on the binary, which will have no effect on the uid of the running server. (Of course, my suggestion will interact w/ that change, since the process that starts Xorg will no longer be root.) I don't think that that will be very useful, it will likely cause more breakage then you think, as various display-managers may already start Xorg inside the user session, at which point the suid bit is needed, and as you already said it will break xinit and friends. This is an empirical question :) gdm on F20, at least, can still switch users with the setuid bit cleared. I'll try to test some more display managers. Besides that almost every Fedora system already has a copy of the X server running as root ready to be exploited. The attack service of X is not its cmdline or attacks through environment settings (2 vectors your suggestion would close), but rather the gargantuan API it exposes over the X protocol itself. There's currently a big attack surface if I run some daemon that gets remotely pwned -- the attacker could start a brand new X server and try to exploit it. On the other hand, they'd have a much more limited attack surface against the already running daemon, because they'll have trouble getting past the X authentication checks. It may be that XorgWithoutRootRights will clear the setuid bit as well, though. Hopefully, either clear it completely or drop root rights very early on on startup. I hope it clears the bit -- I really don't like the fact that 'X :1' screws with the display. --Andy -- 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: Rawhide PAPI-5.3 rebase warning
On 01/09/2014 01:23 PM, William Cohen wrote: On 01/09/2014 01:29 PM, Orion Poplawski wrote: On 01/09/2014 10:48 AM, William Cohen wrote: PAPI-5.3.0 came out at the beginning of December 2013 (http://icl.cs.utk.edu/papi/news/news.html?id=331). I would like to rebase Fedora rawhide PAPI to PAPI-5.3.0 January 16, 2014. openmpi build is definitely dependent on papi-devel, but I don't know if there are any other packages dependent on papi. -Will I don't see any other users as well. It would be nice to test a build of openmpi against papi 5.3.0 before pushing it to rawhide just to see. Hi, There is a papi-5.3.0-1 scratch build in koji at: http://koji.fedoraproject.org/koji/taskinfo?taskID=6380410 Please give that a try for openmpi build and let me know if whether it works. -Will Builds fine, so feel free any time from my perspective. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
On 01/09/2014 01:58 PM, Ian Malone wrote: Latest installed is almost exactly not what you want, I've had plenty (where plenty in this case is probably 5) of cases where a kernel update broke something, in quite a few of those cases to a state where the system wouldn't boot. If the most recent one is retained then you've still got a kernel, but not one that will actually run. With current behaviour I can still let my system update until a fix appears because I know it won't remove the good kernel. If updates can remove the running kernel then you have to watch each one carefully. Right, so if you run into a situation where you need to run an old kernel-0.99, you'd protect it with /etc/yum/protected.d/kernel-0.99.conf , assuming that yum allows specifying package version as well as the name. By the way, currently the protected list seems to be 'yum, systemd and running kernel'. I don't have a system to try it on, so I just hope that one can't delete their dependencies either (glibc? what else?). I think you can still brick the system with careless yum erases: for instance, deleting grub/. /That's why I like the approach of explicitly protecting against removal via .conf files---even though I don't see how to preserve the protection of the currently running kernel in this scheme. / / -- 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: Sub-package dropped upstream
Yes, still it's an interesting issue... perhaps one count how many which actually are installed, but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. In any case it would be great to have some estimate on this. On Thu, Jan 9, 2014 at 9:40 PM, Michael Schwendt mschwe...@gmail.comwrote: On Thu, 9 Jan 2014 12:08:49 -0800, Jorge Gallegos wrote: Hi, I maintain the uwsgi package for fedora, which optionally builds a bunch of modules to integrate with several other languages. One of the plugins got recently removed upstream but it hasn't got any replacements yet (see the top of http://uwsgi-docs.readthedocs.org/en/latest/Erlang.html) Currently f19 and f20 have 1.9.19 available, and I would like to update to 1.9.21 but that would mean I have to deprecate the existing package uwsgi-plugin-erlang. Is this the correct approach? adding an obsoletes tag in the spec for uwsgi-plugin-erlang 1.9.20 ? That would be the only way to withdraw the package from users' installations, especially if not obsoleting it would result in broken dependencies. https://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages Depending on how popular the package might be, such breakage could annoy users. Tangential question, do we have statistics of how many times this (or any other) package has been downloaded? Hardly feasible, given that every mirror server would need to count downloads and submit the results to the Fedora Project, and then one could still not conclude safely whether a package has been installed actually and is still in use (or has been downloaded/mirrored only). -- 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: Sub-package dropped upstream
On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: Yes, still it's an interesting issue... perhaps one count how many which actually are installed, Installed and used actively would be more interesting. Especially with regard to optional plugins, which perhaps are not loaded/executed at runtime automatically. For example, multimedia users follow instructions found on the web that lead to installing all codec packages, whether they need them or not. Watching statistics you might think hey, there are WavPack or Musepack users, but maybe they never use files of that type. but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. And it wouldn't force a packager in any way, maybe serve as some minor influence only. It would not be the first plugin/subpackage that has been discontinued during the lifetime of a distribution. If a package were considered popular enough, the packager would not want to upgrade the software to a newer version that removes the package? There are other more important factors when considering a version upgrade. And probably most important, you cannot get an obsolete package to reinstall automatically once it would become available again. User would need to take notice and reinstall manually (unless packager plays tricks or makes it a new requirement). -- 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: Sub-package dropped upstream
On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote: On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: Yes, still it's an interesting issue... perhaps one count how many which actually are installed, Installed and used actively would be more interesting. Especially with regard to optional plugins, which perhaps are not loaded/executed at runtime automatically. For example, multimedia users follow instructions found on the web that lead to installing all codec packages, whether they need them or not. Watching statistics you might think hey, there are WavPack or Musepack users, but maybe they never use files of that type. it'd be interesting to know how debian QA takes metrics like these: http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flaskshow_installed=onwant_legend=onfrom_date=to_date=hlght_date=date_fmt=%25Ybeenhere=1 I haven't looked but pretty sure these are not recorded via some unauthorized callback (being debian and all), perhaps these are just rough download statistics. but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. And it wouldn't force a packager in any way, maybe serve as some minor influence only. It would not be the first plugin/subpackage that has been discontinued during the lifetime of a distribution. If a package were considered popular enough, the packager would not want to upgrade the software to a newer version that removes the package? There are other more important factors when considering a version upgrade. And probably most important, you cannot get an obsolete package to reinstall automatically once it would become available again. User would need to take notice and reinstall manually (unless packager plays tricks or makes it a new requirement). The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- ~kad pgpI50ulv0_vh.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
On Thu, Jan 09, 2014 at 02:38:50PM -0800, Jorge Gallegos wrote: On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote: On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: Yes, still it's an interesting issue... perhaps one count how many which actually are installed, Installed and used actively would be more interesting. Especially with regard to optional plugins, which perhaps are not loaded/executed at runtime automatically. For example, multimedia users follow instructions found on the web that lead to installing all codec packages, whether they need them or not. Watching statistics you might think hey, there are WavPack or Musepack users, but maybe they never use files of that type. it'd be interesting to know how debian QA takes metrics like these: http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flaskshow_installed=onwant_legend=onfrom_date=to_date=hlght_date=date_fmt=%25Ybeenhere=1 I haven't looked but pretty sure these are not recorded via some unauthorized callback (being debian and all), perhaps these are just rough download statistics. Hah!, found it right after I sent the email: http://popcon.debian.org but many problems also here: users privacy/opt-in, easily spoofed, infrastructure. And it wouldn't force a packager in any way, maybe serve as some minor influence only. It would not be the first plugin/subpackage that has been discontinued during the lifetime of a distribution. If a package were considered popular enough, the packager would not want to upgrade the software to a newer version that removes the package? There are other more important factors when considering a version upgrade. And probably most important, you cannot get an obsolete package to reinstall automatically once it would become available again. User would need to take notice and reinstall manually (unless packager plays tricks or makes it a new requirement). The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- ~kad -- ~kad pgpgbpHaw4nIi.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Sub-package dropped upstream
On Thu, 9 Jan 2014 14:38:50 -0800, Jorge Gallegos wrote: The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) If upstream renames it, too, moving the Obsoletes to that _new_ subpackage doesn't add much value, since it would only affect people who have kept the old package. If upstream doesn't rename it, you can let the package return with a %version-%release higher than what you've specified in the Obsoletes tag. The packaging guidelines section explains that. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: dnf versus yum
Chris Adams wrote: The rescue kernel is another option, right there on the boot menu; if you actually removed all running kernels, it would be the _only_ Fedora option (and the only option at all on a system without multiple OSes installed, so booted by default). Not going to happen here, I use the nohostonly and norescue options to disable that nonsense feature. So removing all kernels will not only make the system unbootable for the lack of a kernel, but also leave grub.cfg with no kernel listed at all, and thus grubby without a template to write new kernel entries from, ergo I would not only have to reinstall the kernel from a rescue environment, but also manually fix grub.cfg! (Maybe grub2-mkconfig would be sufficient for that purpose these days though. In GRUB 1 days, it meant having to write the entry by hand!) 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: dnf versus yum
Bill Nottingham wrote: Matthew Miller (mat...@fedoraproject.org) said: I'm a little lost in the thread, but do you mean that yum's protected packages functionality is undocumented? If that is what you mean, check the man page. It says: protected_packages This is a list of packages that yum should never completely remove. They are protected via Obsoletes as well as user/plugin removals. The default is: yum glob:/etc/yum/protected.d/*.conf So any packages which should be protected can do so by including a file in /etc/yum/protected.d with their package name in it. Also if this configuration is set to anything, then yum will protect the package corresponding to the running version of the kernel. While documented, I do find this last bit of behavior extremely odd and non-intuitive. (And hardcoded, no less.) There should just be a separate protect_running_kernel boolean option, which would default to the above odd behavior for compatibility if not set (but explicitly setting it to either 1 or 0 would override that either way). 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: dnf versus yum
Am 09.01.2014 22:16, schrieb Przemek Klosowski: By the way, currently the protected list seems to be 'yum, systemd and running kernel'. I don't have a system to try it on what about the machine you sitting in front of? without -y flag yum asks if you mean your input serious so I just hope that one can't delete their dependencies either (glibc? what else?) if you think one second about dependencies are solved you know what happens you try tu remove glibc, all packages depending on glibc are resursive resloved and finally one of them is yum - what happens: it stops and that is why yum is and should be protected I think you can still brick the system with careless yum erases: for instance, deleting grub how would this delete the bootloader in the MBR? you do not need the grub-package installed to have a bootloader 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: Should /usr/bin/Xorg (still) be setuid-root?
On Thu, Jan 09, 2014 at 12:52:46PM -0800, Andrew Lutomirski wrote: On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/09/2014 12:09 AM, Andrew Lutomirski wrote: On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote: /usr/bin/Xorg is, and has been, setuid-root just about forever. I'm wondering whether there's any good reason for it to remain setuid-root. http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This isn't actually the same thing. That proposal suggests running Xorg as a non-root user. I'm proposing dropping the setuid bit on the binary, which will have no effect on the uid of the running server. (Of course, my suggestion will interact w/ that change, since the process that starts Xorg will no longer be root.) I don't think that that will be very useful, it will likely cause more breakage then you think, as various display-managers may already start Xorg inside the user session, at which point the suid bit is needed, and as you already said it will break xinit and friends. This is an empirical question :) gdm on F20, at least, can still switch users with the setuid bit cleared. I'll try to test some more display managers. Besides that almost every Fedora system already has a copy of the X server running as root ready to be exploited. The attack service of X is not its cmdline or attacks through environment settings (2 vectors your suggestion would close), but rather the gargantuan API it exposes over the X protocol itself. There's currently a big attack surface if I run some daemon that gets remotely pwned -- the attacker could start a brand new X server and try to exploit it. On the other hand, they'd have a much more limited attack surface against the already running daemon, because they'll have trouble getting past the X authentication checks. It may be that XorgWithoutRootRights will clear the setuid bit as well, though. Hopefully, either clear it completely or drop root rights very early on on startup. I hope it clears the bit -- I really don't like the fact that 'X :1' screws with the display. You understand that this isn't as much screwing with the display as being a base functionality of the x server? It's a bit like saying starting apache screws with your port 80 when you start it. Cheers, 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: Should /usr/bin/Xorg (still) be setuid-root?
On Thu, Jan 9, 2014 at 4:27 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Thu, Jan 09, 2014 at 12:52:46PM -0800, Andrew Lutomirski wrote: On Thu, Jan 9, 2014 at 11:43 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/09/2014 12:09 AM, Andrew Lutomirski wrote: On Wed, Jan 8, 2014 at 2:58 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Jan 08, 2014 at 01:14:08PM -0800, Andrew Lutomirski wrote: /usr/bin/Xorg is, and has been, setuid-root just about forever. I'm wondering whether there's any good reason for it to remain setuid-root. http://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This isn't actually the same thing. That proposal suggests running Xorg as a non-root user. I'm proposing dropping the setuid bit on the binary, which will have no effect on the uid of the running server. (Of course, my suggestion will interact w/ that change, since the process that starts Xorg will no longer be root.) I don't think that that will be very useful, it will likely cause more breakage then you think, as various display-managers may already start Xorg inside the user session, at which point the suid bit is needed, and as you already said it will break xinit and friends. This is an empirical question :) gdm on F20, at least, can still switch users with the setuid bit cleared. I'll try to test some more display managers. Besides that almost every Fedora system already has a copy of the X server running as root ready to be exploited. The attack service of X is not its cmdline or attacks through environment settings (2 vectors your suggestion would close), but rather the gargantuan API it exposes over the X protocol itself. There's currently a big attack surface if I run some daemon that gets remotely pwned -- the attacker could start a brand new X server and try to exploit it. On the other hand, they'd have a much more limited attack surface against the already running daemon, because they'll have trouble getting past the X authentication checks. It may be that XorgWithoutRootRights will clear the setuid bit as well, though. Hopefully, either clear it completely or drop root rights very early on on startup. I hope it clears the bit -- I really don't like the fact that 'X :1' screws with the display. You understand that this isn't as much screwing with the display as being a base functionality of the x server? It's a bit like saying starting apache screws with your port 80 when you start it. Except that apache doesn't screw with your port 80 if you try to start it as nonroot :) In a similar vein, chvt doesn't work unless you're root. I don't see why X should be special, other than for rather old historical reasons. I'm pretty sure that the last time I tried to use 'startx' was when I sat down directly in front of the SPARCstation because other people were using all X terminals. Even then, most of the time I'd be sitting at the X terminal with a xterm and nothing else, and I'd just run an mwm session instead of running a whole X server. Of course, back then my password was sent over the network as clear text every time I typed it. No one needed to pwn an X server -- you could get anyone's password by leaving a fake getty running on the modem pool. It would be possible to arrange for running Xorg to still work if you're in a new xorg group. --Andy -- 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: Inter-WG coordination: Stable application runtimes
On Fri, 2013-12-20 at 00:03 +0100, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: In case of 3 you would never update an container you would replace it with a new container ( or App image rather ) which contains the update/upgrade and delete the old container or in case of Gnome with a new App image If I understood Alexander correctly at that BOF at guadec. Personally I think we should entirely drop any notion of implementing software collection in Fedora on rpm bases ( could be implemented as standalone app image ) since we dont need it RHEL does [1] and go directly looking at implementing Alexander's proposal regarding app images. Argh, no thanks! App images are even worse than SCLs. They are a security nightmare, an immense waste of disk space and RAM, and just generally a totally broken concept. Applications need to stop thinking they are a distribution! Such applications-that-think-they're-distros are a horrible mess to deal with, and generally the only sane way to handle them is to untangle that distro-in-a-distro mess and package them as normal applications. (See e.g. what we have done to SAGE(Math) to package it for Fedora. Now it is a sane package using system versions of its dependencies rather than a huge multi-hundred-MiB tarball bundling even things like Python and Maxima!) Coming to this discussion late, but I do think it's an interesting one. There's a deep question lurking behind the scenes here, which is: what is the distro's responsibility, exactly? People are already deploying static bundled stacks on Fedora. There are large ecosystems where this has become the norm: Javaland, PHPland, Rubyland. A lot of people don't deploy their Java or PHP or Ruby apps from their distribution's repositories, they use an overlaid distribution mechanism of some kind which promotes the use of bundled dependencies to provide a 'stable' stack. You may think they're wrong, I may think they're wrong, but they're doing it. It is very very difficult to 'convert' these entire ecosystems into sets of packages that obey the traditional policies of Linux distributions regarding bundling; in practice it's probably impossible to do so in a way that people actually involved in those ecosystems are happy with, which is why they bypass distro mechanisms. We don't have anywhere near a full Ruby or PHP or Java ecosystem packaged for Fedora, and the packages we do have are frequently broken or outdated, precisely because of this major mismatch between how we do things and how those ecosystems do things. So the question becomes, what is it appropriate for a distribution to do in this situation? My personal opinion is that what's appropriate for a distribution to do is also, happily, what's easiest for a distribution to do: punt on it. Entirely punt on the whole thing. There are already multiple mechanisms for the deployment of bundled software stacks, many associated with a given ecosystem - Composer for PHPland, npm for NodeJSland, bundler for Rubyland, etc etc. We've seen that GNOMEland is apparently looking down a similar path for deploying 'app bundles', and will no doubt come up with its own mechanism. I doubt a distribution can come up with a Single Bundled Stack Deployment Mechanism To Rule Them All, or something like that, and it is a layering violation for this kind of mechanism to be owned by a distribution: they should be - and in practice *are* - owned by their ecosystems. I'm coming to the conclusion that at some point distros have to give up swimming against the tide and just say, look, if this is the way this ecosystem wants to go, then it's your problem. Fedora's job for such ecosystems would simply be to make sure their distribution mechanism works on top of Fedora - if it's one we care about - and then butt out. I'm not sure we're achieving anything practical for anyone by bending PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform to Fedora's packaging guidelines (often at the cost that we have to turn stuff off, or break stuff, or be months or years behind upstream, or be massively incomplete), and I say this as someone who's spent the last couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to achieve precisely that. Distros can work with ecosystems - like the roughly defined 'basic *nix userland' ecosystem - which are written in C and C++ and Bash and Python and Perl, and where libraries understand the value of well-defined and widely observed policies regarding API/ABI stability and library versioning and so on. I suspect the only way distros can really 'work' with ecosystems that don't do so is to stop trying and leave them to it. So to bring it to the context of Fedora.next - if some of the 'Fedora.next' products want to have the capability to deploy 'stable', i.e. bundled, stacks, then I think they should be 'allowed' to do so (in the sense that we can't really stop them), but the mechanisms used to do so
Re: Inter-WG coordination: Stable application runtimes
On Thu, 2014-01-09 at 19:58 -0800, Adam Williamson wrote: I'm coming to the conclusion that at some point distros have to give up swimming against the tide and just say, look, if this is the way this ecosystem wants to go, then it's your problem. Fedora's job for such ecosystems would simply be to make sure their distribution mechanism works on top of Fedora - if it's one we care about - and then butt out. I'm not sure we're achieving anything practical for anyone by bending PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform to Fedora's packaging guidelines (often at the cost that we have to turn stuff off, or break stuff, or be months or years behind upstream, or be massively incomplete), and I say this as someone who's spent the last couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to achieve precisely that. A further point on this: I think distros can probably provide value to these stacks if they're clever and take a strategic approach. To take the example of PHPland, which is the one I've been dealing with the most lately, there are some libraries and frameworks which are required by a *lot* of PHP project, and which do have a _reasonable_ approach to stability. It's probably the case that Fedora can provide value by, for instance, providing packaged versions of Zend and Doctrine and Symfony - major stacks/libs/frameworks which don't break their APIs every Wednesday, have reasonable distribution mechanisms, and which quite a lot of popular projects depend on. But when I'm sitting here building a package for some garbage PHP 'library' which doesn't have a release mechanism or a versioning policy or any concept of API stability - where all you have is a git repo with one or two branches into which they regularly stuff anything from a bug fix to a major refactoring - I wonder exactly who I'm helping. Probably there are three projects in the world which use that library and each one uses a different random git checkout from the others which is in no way compatible. When you're working in that kind of context, trying to apply distribution packaging rules is like showing up to a UFC fight with a copy of the Queensberry rules and attempting to convince everyone they're doing it wrong: you're not really doing anything of any use to anyone involved. -- 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: Inter-WG coordination: Stable application runtimes
On Thu, Jan 9, 2014 at 7:58 PM, Adam Williamson awill...@redhat.com wrote: On Fri, 2013-12-20 at 00:03 +0100, Kevin Kofler wrote: Jóhann B. Guðmundsson wrote: In case of 3 you would never update an container you would replace it with a new container ( or App image rather ) which contains the update/upgrade and delete the old container or in case of Gnome with a new App image If I understood Alexander correctly at that BOF at guadec. Personally I think we should entirely drop any notion of implementing software collection in Fedora on rpm bases ( could be implemented as standalone app image ) since we dont need it RHEL does [1] and go directly looking at implementing Alexander's proposal regarding app images. Argh, no thanks! App images are even worse than SCLs. They are a security nightmare, an immense waste of disk space and RAM, and just generally a totally broken concept. Applications need to stop thinking they are a distribution! Such applications-that-think-they're-distros are a horrible mess to deal with, and generally the only sane way to handle them is to untangle that distro-in-a-distro mess and package them as normal applications. (See e.g. what we have done to SAGE(Math) to package it for Fedora. Now it is a sane package using system versions of its dependencies rather than a huge multi-hundred-MiB tarball bundling even things like Python and Maxima!) Coming to this discussion late, but I do think it's an interesting one. There's a deep question lurking behind the scenes here, which is: what is the distro's responsibility, exactly? People are already deploying static bundled stacks on Fedora. There are large ecosystems where this has become the norm: Javaland, PHPland, Rubyland. A lot of people don't deploy their Java or PHP or Ruby apps from their distribution's repositories, they use an overlaid distribution mechanism of some kind which promotes the use of bundled dependencies to provide a 'stable' stack. You may think they're wrong, I may think they're wrong, but they're doing it. It is very very difficult to 'convert' these entire ecosystems into sets of packages that obey the traditional policies of Linux distributions regarding bundling; in practice it's probably impossible to do so in a way that people actually involved in those ecosystems are happy with, which is why they bypass distro mechanisms. We don't have anywhere near a full Ruby or PHP or Java ecosystem packaged for Fedora, and the packages we do have are frequently broken or outdated, precisely because of this major mismatch between how we do things and how those ecosystems do things. So the question becomes, what is it appropriate for a distribution to do in this situation? My personal opinion is that what's appropriate for a distribution to do is also, happily, what's easiest for a distribution to do: punt on it. Entirely punt on the whole thing. There are already multiple mechanisms for the deployment of bundled software stacks, many associated with a given ecosystem - Composer for PHPland, npm for NodeJSland, bundler for Rubyland, etc etc. We've seen that GNOMEland is apparently looking down a similar path for deploying 'app bundles', and will no doubt come up with its own mechanism. I doubt a distribution can come up with a Single Bundled Stack Deployment Mechanism To Rule Them All, or something like that, and it is a layering violation for this kind of mechanism to be owned by a distribution: they should be - and in practice *are* - owned by their ecosystems. I'm coming to the conclusion that at some point distros have to give up swimming against the tide and just say, look, if this is the way this ecosystem wants to go, then it's your problem. Fedora's job for such ecosystems would simply be to make sure their distribution mechanism works on top of Fedora - if it's one we care about - and then butt out. I'm not sure we're achieving anything practical for anyone by bending PHP / Java / nodejs / Ruby packages 120 degrees out of shape to conform to Fedora's packaging guidelines (often at the cost that we have to turn stuff off, or break stuff, or be months or years behind upstream, or be massively incomplete), and I say this as someone who's spent the last couple of weeks whacking on a PHPland stack (Owncloud) with a wrench to achieve precisely that. Distros can work with ecosystems - like the roughly defined 'basic *nix userland' ecosystem - which are written in C and C++ and Bash and Python and Perl, and where libraries understand the value of well-defined and widely observed policies regarding API/ABI stability and library versioning and so on. I suspect the only way distros can really 'work' with ecosystems that don't do so is to stop trying and leave them to it. So to bring it to the context of Fedora.next - if some of the 'Fedora.next' products want to have the capability to deploy 'stable', i.e. bundled, stacks, then I
File Glib-1.304.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Glib: 62e454da4eb8eccdb59452c8bfd8565c Glib-1.304.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Glib] 1.304 bump
commit e46e86dc43dd23e966f47d0bd108d13740c03f35
Author: Petr Písař ppi...@redhat.com
Date: Thu Jan 9 10:39:09 2014 +0100
1.304 bump
.gitignore |1 +
perl-Glib.spec | 25 +
sources|2 +-
3 files changed, 23 insertions(+), 5 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9f33619..6bc6d36 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@ Glib-1.223.tar.gz
/Glib-1.241.tar.gz
/Glib-1.260.tar.gz
/Glib-1.280.tar.gz
+/Glib-1.304.tar.gz
diff --git a/perl-Glib.spec b/perl-Glib.spec
index 2f440b7..f235f59 100644
--- a/perl-Glib.spec
+++ b/perl-Glib.spec
@@ -1,32 +1,46 @@
Name: perl-Glib
-Version:1.280
-Release:4%{?dist}
+Version:1.304
+Release:1%{?dist}
Summary:Perl interface to GLib
Group: Development/Libraries
License:LGPLv2+
URL:http://search.cpan.org/dist/Glib/
Source0:http://www.cpan.org/authors/id/X/XA/XAOC/Glib-%{version}.tar.gz
-BuildRequires: perl = 2:5.8.0
BuildRequires: glib2-devel
-BuildRequires: perl(Carp)
+BuildRequires: perl = 2:5.8.0
BuildRequires: perl(Cwd)
BuildRequires: perl(ExtUtils::Depends) = 0.300
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(ExtUtils::PkgConfig) = 1.00
BuildRequires: perl(File::Spec)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
# Run-time
BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+# Config not used by tests
BuildRequires: perl(constant)
BuildRequires: perl(Data::Dumper)
BuildRequires: perl(DynaLoader)
BuildRequires: perl(Exporter)
+# Gtk2 not used and optional
BuildRequires: perl(IO::File)
+BuildRequires: perl(overload)
+# POSIX not used by tests
BuildRequires: perl(Storable)
+BuildRequires: perl(vars)
# Tests
+BuildRequires: perl(Config)
BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Test::More)
BuildRequires: perl(Tie::Hash)
+BuildRequires: perl(utf8)
+# Optional tests:
+BuildRequires: perl(I18N::Langinfo)
+BuildRequires: perl(Test::ConsistentVersion)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Config)
+Requires: perl(overload)
# Do not export private modules and libraries
%{?perl_default_filter}
@@ -96,6 +110,9 @@ make test
%{_mandir}/man3/Glib::xsapi.3pm.gz
%changelog
+* Thu Jan 09 2014 Petr Pisar ppi...@redhat.com - 1.304-1
+- 1.304 bump
+
* Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.280-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
diff --git a/sources b/sources
index 0fe6735..808b67f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-1d81a8aec5f7f1182a96cfaaf119d866 Glib-1.280.tar.gz
+62e454da4eb8eccdb59452c8bfd8565c Glib-1.304.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Glib] Fix changelog entry
commit 5d4b6f7c422191a7dbad3238505b1b08f61938d7 Author: Petr Písař ppi...@redhat.com Date: Thu Jan 9 10:40:36 2014 +0100 Fix changelog entry perl-Glib.spec |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) --- diff --git a/perl-Glib.spec b/perl-Glib.spec index f235f59..a5f41b3 100644 --- a/perl-Glib.spec +++ b/perl-Glib.spec @@ -245,7 +245,7 @@ make test * Mon Jun 27 2005 Jose Pedro Oliveira jpo at di.uminho.pt - 1.082-1 - Update to 1.082. -* Fri Apr 7 2005 Michael Schwendt mschwendt[AT]users.sf.net +* Wed Apr 6 2005 Michael Schwendt mschwendt[AT]users.sf.net - rebuilt * Tue Mar 8 2005 Jose Pedro Oliveira jpo at di.uminho.pt - 1.080-1 -- 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-Glib/f20] (2 commits) ...Fix changelog entry
Summary of changes: e46e86d... 1.304 bump (*) 5d4b6f7... Fix changelog entry (*) (*) 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1044943] perl-Gtk2 GUI programs fails to start when using DBD::Pg
https://bugzilla.redhat.com/show_bug.cgi?id=1044943 --- Comment #8 from Petr Pisar ppi...@redhat.com --- This bug report will be used for tracking the Glib incompatibility. -- 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=G5xzgsl0zha=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
[Bug 1044943] perl-Gtk2 GUI programs fails to start when using DBD::Pg
https://bugzilla.redhat.com/show_bug.cgi?id=1044943 --- Comment #9 from Fedora Update System upda...@fedoraproject.org --- perl-Glib-1.304-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Glib-1.304-1.fc20 -- 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=MAEtJBKcGga=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-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
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: 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1051106] perl-PlRPC: weak crypto
https://bugzilla.redhat.com/show_bug.cgi?id=1051106 Ratul Gupta rat...@redhat.com changed: What|Removed |Added CC||bgoll...@redhat.com, ||drie...@redhat.com, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ||perl-maint-l...@redhat.com, ||pfrie...@redhat.com, ||ppi...@redhat.com, ||psab...@redhat.com, ||tdaw...@redhat.com, ||tkra...@redhat.com -- 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=Mg53v4HBd9a=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
[Bug 1051108] perl-PlRPC: pre-auth remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1051108 Ratul Gupta rat...@redhat.com changed: What|Removed |Added CC||bgoll...@redhat.com, ||drie...@redhat.com, ||mmasl...@redhat.com, ||perl-devel@lists.fedoraproj ||ect.org, ||perl-maint-l...@redhat.com, ||pfrie...@redhat.com, ||ppi...@redhat.com, ||psab...@redhat.com, ||tdaw...@redhat.com, ||tkra...@redhat.com -- 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=7k3jBFxrZKa=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
[Bug 1051110] New: perl-PlRPC: weak crypto [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1051110 Bug ID: 1051110 Summary: perl-PlRPC: weak crypto [fedora-all] Product: Fedora Version: 20 Component: perl-PlRPC Keywords: Security, SecurityTracking Severity: medium Priority: medium Assignee: ppi...@redhat.com Reporter: rat...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, psab...@redhat.com Blocks: 1051106 This is an automatically created tracking bug! It was created to ensure that one or more security vulnerabilities are fixed in affected versions of Fedora. For comments that are specific to the vulnerability please use bugs filed against the Security Response product referenced in the Blocks field. For more information see: http://fedoraproject.org/wiki/Security/TrackingBugs When creating a Bodhi update request, please use the bodhi submission link noted in the next comment(s). This will include the bug IDs of this tracking bug as well as the relevant top-level CVE bugs. Please also mention the CVE IDs being fixed in the RPM changelog and the Bodhi notes field when available. Please note: this issue affects multiple supported versions of Fedora. Only one tracking bug has been filed; please ensure that it is only closed when all affected versions are fixed. [bug automatically created by: add-tracking-bugs] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1051106 [Bug 1051106] perl-PlRPC: weak crypto -- 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=ezmRo1eO9Sa=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
[Bug 1051106] perl-PlRPC: weak crypto
https://bugzilla.redhat.com/show_bug.cgi?id=1051106 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Depends On||1051110 --- Comment #1 from Ratul Gupta rat...@redhat.com --- Created perl-PlRPC tracking bugs for this issue: Affects: fedora-all [bug 1051110] Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1051110 [Bug 1051110] perl-PlRPC: weak crypto [fedora-all] -- 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=kHa07ySiFCa=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
[Bug 1051110] perl-PlRPC: various flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1051110 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Summary|perl-PlRPC: weak crypto |perl-PlRPC: various flaws |[fedora-all]|[fedora-all] -- 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=MDGu4JleYHa=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
[Bug 1051108] perl-PlRPC: pre-auth remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1051108 --- Comment #1 from Ratul Gupta rat...@redhat.com --- Created perl-PlRPC tracking bugs for this issue: Affects: fedora-all [bug 1051110] -- 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=q3GmEfeaJPa=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
[Bug 1051110] perl-PlRPC: various flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1051110 --- Comment #2 from Ratul Gupta rat...@redhat.com --- Adding parent bug 1051108. Please use this new bodhi update url when correcting these flaws: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=1051110,1051106,1051108 -- 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=TF07VcLCesa=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
[Bug 1051108] perl-PlRPC: pre-auth remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1051108 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Depends On||1030572 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1030572 [Bug 1030572] perl-PlRPC: not secure across trust boundaries -- 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=bNBRn2jhqba=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
[Bug 1051106] perl-PlRPC: weak crypto
https://bugzilla.redhat.com/show_bug.cgi?id=1051106 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Depends On||1030572 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1030572 [Bug 1030572] perl-PlRPC: not secure across trust boundaries -- 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=IqfiMiPB8Ta=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
[Bug 1051106] perl-PlRPC: weak crypto
https://bugzilla.redhat.com/show_bug.cgi?id=1051106 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Blocks||1051112 -- 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=UHgIys2stda=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
[Bug 1051108] perl-PlRPC: pre-auth remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1051108 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Blocks||1051112 -- 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=i35yslmSRya=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
[Bug 1051110] perl-PlRPC: weak crypto [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1051110 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Blocks||1051108 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1051108 [Bug 1051108] perl-PlRPC: pre-auth remote code execution -- 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=1fwTDF8IfOa=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
[Bug 1051108] perl-PlRPC: pre-auth remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1051108 Ratul Gupta rat...@redhat.com changed: What|Removed |Added Depends On||1051110 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1051110 [Bug 1051110] perl-PlRPC: weak crypto [fedora-all] -- 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=prIyYitQTHa=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
[Bug 1051110] perl-PlRPC: weak crypto [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1051110 --- Comment #1 from Ratul Gupta rat...@redhat.com --- Please use the following update submission link to create the Bodhi request for this issue as it contains the top-level parent bug(s) as well as this tracking bug. This will ensure that all associated bugs get updated when new packages are pushed to stable. Please also ensure that the Close bugs when update is stable option remains checked. Bodhi update submission link: https://admin.fedoraproject.org/updates/new/?type_=securitybugs=1051106,1051110 -- 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=pOAEX0P6ina=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
[Bug 1051106] perl-PlRPC: weak crypto
https://bugzilla.redhat.com/show_bug.cgi?id=1051106 --- Comment #2 from Vincent Danen vda...@redhat.com --- The actual proposed patch to upstream is here: * https://rt.cpan.org/Public/Ticket/Attachment/1289399/683202/0001-Security-notice-for-Proxy.patch As per http://seclists.org/oss-sec/2014/q1/62 MITRE has held off assigning any CVEs for this weak crypto issue. -- 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=9UN6z1dDHLa=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
[Bug 1051108] CVE-2013-7284 perl-PlRPC: pre-auth remote code execution
https://bugzilla.redhat.com/show_bug.cgi?id=1051108 Vincent Danen vda...@redhat.com changed: What|Removed |Added Summary|perl-PlRPC: pre-auth remote |CVE-2013-7284 perl-PlRPC: |code execution |pre-auth remote code ||execution Alias||CVE-2013-7284 --- Comment #2 from Vincent Danen vda...@redhat.com --- The actual proposed patch to upstream is here: * https://rt.cpan.org/Public/Ticket/Attachment/1293961/685696/0001-Security-notice-on-Storable-and-reply-attack.patch Based on the discussion in bug #1030572, there is no real fix for this as it seems that Storable deserialization is exposed prior to password-based authentication (see how AcceptUser is called in the server code). MITRE assigned CVE-2013-7284 to this issue. -- 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=uXNOYdCEBka=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Lingua-EN-Fathom-1.15.tar.gz uploaded to lookaside cache by rlandmann
A file has been added to the lookaside cache for perl-Lingua-EN-Fathom: 94bd7ecf1f9b460fb090f478a39acdfd Lingua-EN-Fathom-1.15.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Lingua-EN-Fathom/f20] New package
commit 7d6f04c9c1899cd423637ce2c8e7bf1b9badcded
Author: Ruediger Landmann r.landm...@redhat.com
Date: Fri Jan 10 09:45:25 2014 +1000
New package
.gitignore |1 +
perl-Lingua-EN-Fathom.spec | 56
sources|1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f7673eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Lingua-EN-Fathom-1.15.tar.gz
diff --git a/perl-Lingua-EN-Fathom.spec b/perl-Lingua-EN-Fathom.spec
new file mode 100644
index 000..3f10ebc
--- /dev/null
+++ b/perl-Lingua-EN-Fathom.spec
@@ -0,0 +1,56 @@
+Name: perl-Lingua-EN-Fathom
+Version:1.15
+Release:2%{?dist}
+Summary:Measure readability of English text
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Lingua-EN-Fathom/
+Source0:
http://www.cpan.org/authors/id/K/KI/KIMRYAN/Lingua-EN-Fathom-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Lingua::EN::Syllable)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+This module analyses English text in either a string or file. Totals are
+then calculated for the number of characters, words, sentences, blank and
+non blank (text) lines and paragraphs.
+
+%prep
+%setup -q -n Lingua-EN-Fathom-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Jan 8 2014 Jeff fearn jfe...@redhat.com 1.15-2
+- Remove unnecessary requires and dircetory clean up command. BZ #1033987
+
+* Mon Nov 04 2013 Jeff fearn jfe...@redhat.com 1.15-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..3e33c9f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+94bd7ecf1f9b460fb090f478a39acdfd Lingua-EN-Fathom-1.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Lingua-EN-Fathom/f19] New package
commit bdb0a16a32c250379f864b6aa0920762131d345f
Author: Ruediger Landmann r.landm...@redhat.com
Date: Fri Jan 10 09:47:08 2014 +1000
New package
.gitignore |1 +
perl-Lingua-EN-Fathom.spec | 56
sources|1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f7673eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Lingua-EN-Fathom-1.15.tar.gz
diff --git a/perl-Lingua-EN-Fathom.spec b/perl-Lingua-EN-Fathom.spec
new file mode 100644
index 000..3f10ebc
--- /dev/null
+++ b/perl-Lingua-EN-Fathom.spec
@@ -0,0 +1,56 @@
+Name: perl-Lingua-EN-Fathom
+Version:1.15
+Release:2%{?dist}
+Summary:Measure readability of English text
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Lingua-EN-Fathom/
+Source0:
http://www.cpan.org/authors/id/K/KI/KIMRYAN/Lingua-EN-Fathom-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Lingua::EN::Syllable)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+This module analyses English text in either a string or file. Totals are
+then calculated for the number of characters, words, sentences, blank and
+non blank (text) lines and paragraphs.
+
+%prep
+%setup -q -n Lingua-EN-Fathom-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Jan 8 2014 Jeff fearn jfe...@redhat.com 1.15-2
+- Remove unnecessary requires and dircetory clean up command. BZ #1033987
+
+* Mon Nov 04 2013 Jeff fearn jfe...@redhat.com 1.15-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..3e33c9f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+94bd7ecf1f9b460fb090f478a39acdfd Lingua-EN-Fathom-1.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Lingua-EN-Fathom/el6] New package
commit 58c91e053d5bbaa3f48113cf8f391c5bb2a1c4df
Author: Ruediger Landmann r.landm...@redhat.com
Date: Fri Jan 10 09:48:15 2014 +1000
New package
.gitignore |1 +
perl-Lingua-EN-Fathom.spec | 56
sources|1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f7673eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Lingua-EN-Fathom-1.15.tar.gz
diff --git a/perl-Lingua-EN-Fathom.spec b/perl-Lingua-EN-Fathom.spec
new file mode 100644
index 000..3f10ebc
--- /dev/null
+++ b/perl-Lingua-EN-Fathom.spec
@@ -0,0 +1,56 @@
+Name: perl-Lingua-EN-Fathom
+Version:1.15
+Release:2%{?dist}
+Summary:Measure readability of English text
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Lingua-EN-Fathom/
+Source0:
http://www.cpan.org/authors/id/K/KI/KIMRYAN/Lingua-EN-Fathom-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Lingua::EN::Syllable)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+This module analyses English text in either a string or file. Totals are
+then calculated for the number of characters, words, sentences, blank and
+non blank (text) lines and paragraphs.
+
+%prep
+%setup -q -n Lingua-EN-Fathom-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Jan 8 2014 Jeff fearn jfe...@redhat.com 1.15-2
+- Remove unnecessary requires and dircetory clean up command. BZ #1033987
+
+* Mon Nov 04 2013 Jeff fearn jfe...@redhat.com 1.15-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..3e33c9f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+94bd7ecf1f9b460fb090f478a39acdfd Lingua-EN-Fathom-1.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Lingua-EN-Fathom/el5] New package
commit 0eb9669e070908789f815dbc78c245ef2a5c
Author: Ruediger Landmann r.landm...@redhat.com
Date: Fri Jan 10 09:49:26 2014 +1000
New package
.gitignore |1 +
perl-Lingua-EN-Fathom.spec | 56
sources|1 +
3 files changed, 58 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..f7673eb 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Lingua-EN-Fathom-1.15.tar.gz
diff --git a/perl-Lingua-EN-Fathom.spec b/perl-Lingua-EN-Fathom.spec
new file mode 100644
index 000..3f10ebc
--- /dev/null
+++ b/perl-Lingua-EN-Fathom.spec
@@ -0,0 +1,56 @@
+Name: perl-Lingua-EN-Fathom
+Version:1.15
+Release:2%{?dist}
+Summary:Measure readability of English text
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/Lingua-EN-Fathom/
+Source0:
http://www.cpan.org/authors/id/K/KI/KIMRYAN/Lingua-EN-Fathom-%{version}.tar.gz
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Lingua::EN::Syllable)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%description
+This module analyses English text in either a string or file. Totals are
+then calculated for the number of characters, words, sentences, blank and
+non blank (text) lines and paragraphs.
+
+%prep
+%setup -q -n Lingua-EN-Fathom-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+rm -rf $RPM_BUILD_ROOT
+
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%clean
+rm -rf $RPM_BUILD_ROOT
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Wed Jan 8 2014 Jeff fearn jfe...@redhat.com 1.15-2
+- Remove unnecessary requires and dircetory clean up command. BZ #1033987
+
+* Mon Nov 04 2013 Jeff fearn jfe...@redhat.com 1.15-1
+- Specfile autogenerated by cpanspec 1.79.
diff --git a/sources b/sources
index e69de29..3e33c9f 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+94bd7ecf1f9b460fb090f478a39acdfd Lingua-EN-Fathom-1.15.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [389-devel] Please review (tests) 47628: port test cases to new DirSrv interface
On 01/08/2014 12:54 PM, Roberto Polli wrote:
Hi Thierry,
before all sorry if in the rest of the answer I may seem too direct. All I say
is obviously imh(opinion|experience) Time is a tyrant :(
On Friday 03 January 2014 16:36:17 thierry bordaz wrote:
Thanks, I also wish you an happy new year and you recover well. It
is great to talk to you again :-) .
Thx++!
I am quite novice with python and my first approach was to use it as
a real object oriented language,
It *is* a real OOL ;)
it is a
common use to wrap methods of class and rather use python as a
functional language (e.g. self.backend.setProperties(...) rather
than 'backend=Backend(); backend.setProperties(..) ')
I'm not indepth with functional programming. Why do you think that's a
functional approach?
...the 'object'...are... the configuration object stored in
'cn=config'. So it prevents the problem of synchronizing the python
object with the 'cn=config' object.
To me that's mostly an ORM approach: in any case that's ok
Hi Roberto,
I will try to answer your concerns but as all of them are valid I
will only give some reasons for the approach I choose.
About OOL vs. functional programing this is not IMH that important.
For example for an instance with N replicas, we can imagine DSAdmin
having N Replica/Backend/Suffix/MappingTree... objects. Instead we
have only one, let's say Replica object, allocated in
__add_brookers__ but this object is not a real object but just gives
access all methods of Replica class.
As I said, having N Replica objects brings a big drawback to
synchronize the objects with what is in the server config. So I
think the __add_brookers__ approach is better.
So the only remaining object is
the DS instance (dirsrv/dsadmin) and methods to access its config.
Does it prevent to use fake directory ? I am not enough familiar
with fakeldap, would you give me an example of why the current
implement would not work with fakeldap ?
Let's see how do we setup the client now:
args = {SER_HOST: LOCALHOST,
SER_PORT: INSTANCE_PORT,
SER_DEPLOYED_DIR: INSTANCE_PREFIX,
SER_SERVERID_PROP: INSTANCE_SERVERID
}
1- instance = DirSrv(verbose=False)
2- instance.allocate(args)
3- if instance.exists(): instance.delete()
4- instance.create()
5- instance.open()
That's quite different from the (imho cleaner) old approach - similar to the
SimpleLDAPObject superclass:
args = {'host': LOCALHOST, 'sslport': 10636}
1- instance = DSAdmin(**args)
I agree with you DSAdmin approach looks definitely simpler. Now
there is some magic behind DSAdmin().
It actually checks if the instance exists, if not it creates it,
then it opens a connection to it.
What I wanted to do in a lib is to give an interface to each
individual action. We may want to create an instance without
establishing a connection to it, or (re)create an instance even if
one already exists.
Your point is valid, we need something simple. So what about adding
a new interface to DirSrv (e.g. NewAndConnect) that would do all the
steps 1-5 ?
Obviously there are plenty of functionalities DSAdmin didn't implement: I
would have put those functionalities (eg. filesystem related, instance
creation removal) in the DSAdminTool class.
You may ask: why having two class DSAdminTool and DSAdmin instead of just one?
1- clear design: as DSAdmin extends SimpleLDAPObject, it should require just a
tcp connection (like SimpleLDAPObject). In this way I can use a mock ldap
implementation to test the LDAP behavior of DSAdmin.
DirSrv also extends SimpleLDAPObject and wrap all its methods
(search/add...) what would prevent it to be use as mock ldap ?
2- all the functionalities requiring filesystem access and instance management
(eg. outside LDAP scope) couldn't be tested by a mock ldap implementation, so
we can just extend the mock for those functionalities.
ok
3- As extending classes (or using mix-ins) in python is really smooth, this
approach would lead to the same usage patterns we have now, but with a
separate, tcp oriented DSAdmin class.
Yes that looks very smart. Couldn't it been done with DirSrv that in
my understanding is similar to DSAdmin ? (except specific interface
to create/open).
About the shift of parameters to dictionary I think both approaches
are valid.
... I used a dictionary to pass
the properties (rather than functions arguments) mainly because some
resource may have many properties, also because all the
set-resource-prop function have a similar interface.
I understand your choice in the view of the CLI. I just think it shouldn't
influence the layout of a class which extends SimpleLDAPObject (see §3 of the
previous statement).
[389-devel] Please review (take 2): [389 Project] #47571: targetattr ACIs ignore subtype
https://fedorahosted.org/389/ticket/47571 https://fedorahosted.org/389/attachment/ticket/47571/0001-Ticket-47571-targetattr-ACIs-ignore-subtype.2.patch Description: Subtypes in targetattr, userattr in aci as well as filter and attribute list in the search are supported. * If targetattr contains subtypes, the base type only as well as other subtypes are not allowed to access (or denied to access). * If userattr contains subtypes, the base type as well as other subtypes in entries do not match the userattr value. * If attribute list in search has a base type attribute, and a targetattr has a type with subtypes, then only the subtyped value is returned. E.g., attribute list: sn targetattr: sn;en == sn;en: sn-en-value and sn;en;phonetic: sn-en-phonetic-value are returned but sn or sn;fr is not. If attribute list has a type with subtype, then if the targetattr allows the subtype, the value is returned. E.g., attribute list: sn;en targetattr: sn;en == sn;en: sn-en-value and sn;en;phonetic: sn-en-phonetic-value are returned but sn or sn;fr is not. 1) slapd/attr.c * slapi_attr_type_cmp assumed the subtype order in 2 args are identical, but it is not always guaranteed. Removed the assumption. * Added another compare type SLAPI_TYPE_CMP_SUBTYPES to comp_cmp which is called by slapi_attr_type_cmp to support full subtypes comparison. 2) plugin/acl.c: * Changed to call slapi_attr_type_cmp with human readable macros, e.g., SLAPI_TYPE_CMP_BASE, SLAPI_TYPE_CMP_SUBTYPE, etc. * Replaced strcasecmp with slapi_attr_type_cmp for attribute type comparison. * Changed to call slapi_attr_type_cmp with SLAPI_TYPE_CMP_SUBTYPES (full subtype comparison) in acl__get_attrEval, where the next attribute to compare is determined. 3) slapd/search.c,result.c send_all_attrs/send_specific_attrs use a dontsendattr array to control the duplicate attribute types. Replaced the logic with a simpler one by creating an charray with no duplicates. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
2013-01-09 @ 16:00 UTC - Fedora QA Devel Meeting Minutes
= #fedora-meeting-2: fedoraqa-devel = We didn't quite get through everything today, so we'll continue after the QA meeting on Monday. I'll be sending an announcement for that meeting shortly. Minutes: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-01-09/fedoraqa-devel.2014-01-09-16.01.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting-2/2014-01-09/fedoraqa-devel.2014-01-09-16.01.txt Log: http://meetbot.fedoraproject.org/fedora-meeting-2/2014-01-09/fedoraqa-devel.2014-01-09-16.01.log.html Meeting summary --- * Roll Call (tflink, 16:01:31) * Current Project Status (tflink, 16:06:34) * Not much is going on with blockerbugs for the short term - we're waiting to see how f21 and/or fedora.next shape out before working on any new features beyond the small changes ready for review (tflink, 16:08:54) * LINK: https://phab.qadevel.cloud.fedoraproject.org/project/view/1/ (tflink, 16:11:22) * Current Status and Plans - resultsdb and testdays (tflink, 16:19:33) * the reduced re-implementation for resultsdb is up and running at http://resultsdb.qa.fedoraproject.org/resultsdb (tflink, 16:21:57) * resultsdb browsing is available at: http://resultsdb.qa.fedoraproject.org/resultsdb_frontend/ (tflink, 16:22:22) * resultsdb API docs are at: http://docs.resultsdb.apiary.io/ (tflink, 16:22:45) * the new resultsdb is (comparing to the old concept) quite simplified on the data level - we stripped all the un-used tables from the old concept, and adapted the data to what we actually used with the autoqa reporting (tflink, 16:28:11) * old and new resultsdb schema displayed at: https://fedoraproject.org/wiki/AutoQA_resultsdb_schema (tflink, 16:29:18) * Current Status - Testday App (tflink, 16:38:15) * the testdays app is IMHO quite self-confined, and I have no immediate goals for changing what it does (apart of bug-fixes). This is because it's using the 'old' resultsdb, and uses TurboGears2 (tflink, 16:40:28) * The plans for the future are to re-write it with Flask New Resultsdb but it is (at the moment) quite low-priority (tflink, 16:42:29) * Current Status - Support Tools (tflink, 16:43:31) * the main support tools that we have are phabricator (code review, issue tracking etc.) and buildbot (in progress)/ jenkins (existing, not quite working) for ci (tflink, 16:47:03) * phabricator is deployed at https://phab.qadevel.cloud.fedoraproject.org/ (tflink, 16:47:22) * LINK: http://phabricator.org/ (Viking-Ice, 16:47:46) * ACTION: tflink to write up docs on code review with phabricator (tflink, 16:49:01) * buildbot for qa project CI is deployed to staging at https://qadevel-stg.cloud.fedoraproject.org/builds/ (tflink, 16:51:59) * there is still work to do on buildbot so that we have CI and hopefully autogenerated and autodeployed docs for qa devel projects (tflink, 16:56:57) * Priorities (tflink, 17:00:36) * AGREED: As we have a longer break between releases for now, automation is a higher priority because it is more disruptive and needs to be done soon (tflink, 17:16:42) * Fedoraproject Beaker Instance Status (tflink, 17:17:26) * we have a dev instance of beaker deployed at https://beaker-dev.fedoraproject.org/bkr/ (tflink, 17:18:11) * due to security concerns, it is currently locked down by IP (tflink, 17:18:29) * ACTION: kparal and tflink to sync up on beaker.fp.o status and come up with some ideas on moving forward (tflink, 17:29:49) * Taskotron status (tflink, 17:29:52) * The hope was to have taskotron phase 0 (https://fedoraproject.org/wiki/User:Tflink/taskotron_development_plan#Phase_0:_Investigation_and_Preparation) done by now (tflink, 17:30:47) * task description format was proposed and sent out to qa-devel@. response has been mostly positive and it is ready to start moving forward (tflink, 17:31:36) * initial fedmsg reliability investigation indicates that it will be reliable enough to use for automation scheduling but we should continue to keep an eye on it (tflink, 17:32:27) * LINK: https://phab.qadevel.cloud.fedoraproject.org/T2 (tflink, 17:32:43) * there was a proof-of-concept system running in the fedora cloud, but it seems to be having issues ATM (tflink, 17:37:54) * The big remaining task for phase 0 is discussion/investigation into notifications (tflink, 17:39:25) * the proof-of-concept runner does work locally and does produce output to the console, it can't report to resultsdb (yet) and needs some refactoring (tflink, 17:40:29) * ACTION: tflink to finish notificaitons email and send it out to qa-devel@ (tflink, 17:42:28) * depcheck scenarios have been drafted up and fake rpms have been coded up for testing (tflink, 17:45:34) * LINK:
