EPEL epel beta report: 20140612 changes
Compose started at Thu Jun 12 08:15:03 UTC 2014
New package: gksu-polkit-0.0.3-10.gitf8ce834c.el7
Command line utility to run programs as root
New package: mingw-glib-networking-2.38.2-2.el7
MinGW Windows glib-networking library
New package: mingw-qt5-qt3d-5.0.0-0.12.git20140525.bdb98ba.el7
Qt5 for Windows - Qt3d component
New package: mingw-qt5-qtdeclarative-5.3.0-2.el7
Qt5 for Windows - QtDeclarative component
New package: mingw-qt5-qtlocation-5.3.0-2.el7
Qt5 for Windows - QtLocation component
New package: mingw-qt5-qtmultimedia-5.3.0-2.el7
Qt5 for Windows - QtMultimedia component
New package: mingw-qt5-qtquick1-5.3.0-2.el7
Qt5 for Windows - QtQuick1 component
New package: mingw-qt5-qtsensors-5.3.0-2.el7
Qt5 for Windows - QtSensors component
New package: mingw-qt5-qtsystems-5.0.0-0.14.git20140323.3f65ffa.el7
Qt5 for Windows - QtSystems component
New package: mingw-qt5-qtwebkit-5.3.0-2.el7
Qt5 for Windows - QtWebKit component
New package: mingw-webkitgtk-2.2.7-2.el7
MinGW Windows web content engine library
New package: mingw-webkitgtk3-2.2.7-2.el7
MinGW Windows GTK+ Web content engine library
New package: php-mikey179-vfsstream-1.2.0-2.el7
PHP stream wrapper for a virtual file system
New package: qfaxreader-0.3.2-2.el7
A multipage monochrome/color TIFF/FAX viewer
New package: tor-0.2.4.22-2.el7
Anonymizing overlay network for TCP (The onion router)
Updated Packages:
cinnamon-2.0.14-18.el7
--
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.14-18
- more X-Cinnamon changes
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.14-17
- switch to X-Cinnamon
cinnamon-control-center-2.0.9-6.el7
---
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.9-6
- make cinnamon-nenu adjustments
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.9-5
- switch to X-Cinnamon
cinnamon-menus-2.2.0-2.el7
--
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.2.0-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
* Sat Apr 12 2014 Leigh Scott leigh123li...@googlemail.com - 2.2.0-1
- update to 2.2.0
cinnamon-screensaver-2.0.3-2.el7
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.3-2
- switch to X-Cinnamon
cinnamon-session-2.0.6-2.el7
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.6-2
- switch to X-Cinnamon
cinnamon-settings-daemon-2.0.8-8.el7
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.8-8
- switch to X-Cinnamon
erlang-R16B-03.7.el7
* Wed Jun 11 2014 Peter Lemenkov lemen...@gmail.com - R16B-03.7
- Added missing template for epmd@.socket
hiera-1.3.4-1.el7
-
* Wed Jun 11 2014 Steve Traylen steve.tray...@cern.ch - 1.3.4-1
- New version 1.3.4
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.3.3-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
mcollective-2.5.2-1.el7
---
* Wed Jun 11 2014 Steve Traylen steve.tray...@cern.ch - 2.5.2-1
- Upstream 2.5.2
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.4.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
nemo-2.0.8-10.el7
-
* Wed Jun 11 2014 Leigh Scott leigh123li...@googlemail.com - 2.0.8-10
- switch to X-Cinnamon
perl-Date-Easter-1.21-1.el7
---
* Thu Jun 12 2014 David Dick dd...@cpan.org - 1.21-1
- Upgrade to 1.21
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.20-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
php-symfony-icu-1.2.1-3.el7
---
* Wed Jun 11 2014 Shawn Iwinski shawn.iwin...@gmail.com - 1.2.1-3
- Added php-composer(%{composer_vendor}/%{composer_project}) virtual provide
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.2.1-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
piglit-1-0.19.20140414GIT8775223.el7
* Wed Jun 11 2014 Matěj Cepl mc...@redhat.com - 1-0.19.20140414GIT8775223
- Add ExcludeArch for EPEL-6 and ppc64 properly (RHBZ# 1093720)
* Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1-0.18.20140414GIT8775223
- Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild
qpid-cpp-0.28-3.el7
---
* Tue Jun 10 2014 Darryl L. Pierce dpie...@redhat.com - 0.28-3
- Fixes alignment issues on ARM platforms.
- Resolves: BZ#1106272
* Sat Jun 07 2014 Peter Robinson
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 782 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6 129 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6 114 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6 73 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1011/php-ZendFramework-1.12.5-1.el6 27 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1414/gajim-0.14.4-4.el6 22 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1471/chicken-4.8.0.6-2.el6 19 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1477/drupal7-views-3.8-1.el6 15 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1522/check-mk-1.2.4p2-2.el6 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1536/xmlsec1-1.2.19-3.el6 9 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1563/mono-2.10.8-2.el6,libgdiplus-2.10-1.el6 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1572/chkrootkit-0.49-9.el6 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1584/python-djblets-0.7.30-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1616/puppet-2.7.26-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1627/php-horde-Horde-Ldap-2.1.0-1.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1608/mcollective-2.2.3-2.el6 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1612/tor-0.2.4.22-1.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1628/hiera-1.0.0-4.el6 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1634/python-django-evolution-0.6.9-4.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing cgit-0.10.1-4.el6 packagedb-cli-2.3.1-1.el6 perl-Date-Easter-1.21-1.el6 php-mikey179-vfsstream-1.2.0-2.el6 ptpd-2.3.0-2.el6 python-click-2.0-2.el6 python-django-evolution-0.6.9-4.el6 rubygem-mixlib-log-1.6.0-1.el6 salt-2014.1.5-1.el6 wicd-1.7.0-5.el6 Details about builds: cgit-0.10.1-4.el6 (FEDORA-EPEL-2014-1640) A fast web interface for git Update Information: Add patch to fix raw patch handling ChangeLog: * Wed Jun 11 2014 Kevin Fenzi ke...@scrye.com 0.10.1-4 - Add patch to fix raw patch handling * Sat Jun 7 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.10.1-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild packagedb-cli-2.3.1-1.el6 (FEDORA-EPEL-2014-1638) A CLI for pkgdb Update Information: Update to 2.3.1 * Fixes to bugs reported on bugzilla * Add to pkgdb2client a method to retrieve the version of the pkgdb API * Add to pgkdb2client a method to retrieve a packager's packages * Have pkgdb-cli list --user rely on the new pkgdb2 API endpoint (if present) * pkgdb-cli list --user returns all the packages unless asked otherwise (which is what it used to do w/ pkgdb1) * Add the pkgdb2client the possibility to save the session to a file ~/.cache/pkgdb-session.pickle by default * Add a login_callback method to pkgdb2client * Fix asking for password only if required (ie: not provided via --password) * Add support for on-demand authentication * Order the user in the ACL output * Order the ACL output per branch ChangeLog: * Thu Jun 12 2014 Pierre-Yves Chibon pin...@pingoured.fr - 2.3.1-1 - Update to 2.3.1 - Fixes https://bugzilla.redhat.com/1108634 (orphaned branches may have no ACLs registered at all) * Tue Jun 10 2014 Pierre-Yves Chibon pin...@pingoured.fr - 2.3-1 - Update to 2.3 - Add to pkgdb2client a method to retrieve the version of the pkgdb API - Add to pgkdb2client a method to retrieve a packager's packages - Have pkgdb-cli list --user rely on the new pkgdb2 API endpoint (if present) - pkgdb-cli list --user returns all the packages unless asked otherwise (which is what it used to do w/ pkgdb1) - Add the pkgdb2client the possibility to save the session to a file ~/.cache/pkgdb-session.pickle by default - Add a login_callback method to pkgdb2client - Fix asking for password only if required (ie: not provided via --password) - Add support for on-demand authentication - Order the user in the ACL output - Order the ACL output per branch * Fri Jun 6 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.2-3 - Rebuilt for
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 782 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 236 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 116 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 15 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1515/check-mk-1.2.4p2-2.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1544/python26-mod_wsgi-3.5-1.el5,mod_wsgi-3.5-1.el5 7 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1575/chkrootkit-0.49-9.el5 1 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1626/puppet-2.7.26-1.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing salt-2014.1.5-1.el5 Details about builds: salt-2014.1.5-1.el5 (FEDORA-EPEL-2014-1642) A parallel remote execution system Update Information: Update to bugfix release 2014.1.5 ChangeLog: * Wed Jun 11 2014 Erik Johnson e...@saltstack.com - 2014.1.5-1 - Update to bugfix release 2014.1.5 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 15:03:12, Przemek Klosowski wrote: On 06/11/2014 11:20 AM, Jan Zelený wrote: The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. I think this is a mistake---if dns truly provides the functionality then it should replace yum. Hopefully the majority of people can use dnf as is, but if there are corner cases that only the original yum handles, then it's better to make it available as, say, 'yum-original' or 'yum --yum-me-harder'. As I said on numerous occasions during the last few days, dnf is not a 100% drop-in replacement of yum. It aims to be as compatible as possible but within reason - one of the important goals of dnf is clean and maintainable design. It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'. As I said, we will have transition layer so using yum in your shell scripts will still work for a few more releases. A vast majority of users should not experience any inconveniences other than different output on the command line. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 18:53:36, Miloslav Trmač wrote: 2014-06-11 15:02 GMT+02:00 Rahul Sundaram methe...@gmail.com: I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those. Yeah, if the compatibility is there, it should *just be there*. Software is here to server users, so the appropriate thing to do on (yum update) is to update the system, not to use this as an appropriate moment to essentially advertise users about a new project or about our achievements (even though the dnf project *is* an achievement, don’t get me wrong). It makes sense to only add new features to the (dnf) command, or to warn/fail when the yum compatibility doesn’t actually exist. But when the compatibility exists, the right thing for the users is to just do what was asked, no questions asked. And indeed it will do what you asked it to do. You will just receive warning that yum is no more and the command should not be used. Again, it's exactly the same what happens when you call service XYZ start and in my opinion it works like a charm. If not for this warning, I'd never learned about systemctl. (Structurally, this would also allow you to separate the compatibility UI hacks in /usr/bin/yum, keeping /usr/bin/dnf a bit more clean.) We plan to have /usr/bin/yum as simple as possible. Just print out a warning and redirect to yum, something like that. As I wrote before, if you want it to do anything else, we welcome the patches. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 18:09:25, Michael Scherer wrote: Le mercredi 11 juin 2014 à 11:37 -0400, Chuck Anderson a écrit : On Wed, Jun 11, 2014 at 05:21:30PM +0200, Jan Zelený wrote: On 11. 6. 2014 at 08:52:34, Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:44:10PM +0200, Jaroslav Reznik wrote: * package 'dnf-yum-compat-command' is installed by default. It obsoletes Yum and provides its own code/usr/bin/yum/code, a short script that redirects to code/usr/bin/dnf/code with an appropriate warning message that DNF is the preferred package manager now. Notice that upgrading F21 to F22 will not cause the compat package to be installed so will not disturb any upgrading users. This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? Actually the plan is to keep /usr/bin/yum as the primary command during the transition but it will do something similar to what the /sbin/service command does now. It will redirect to dnf and give user a message that it is redirecting to dnf. As for scripts, that's actually another reason why to keep yum around. Some scripts might not be able to handle some of the minor differences and some python scripts might still want to use the yum python API. That's why it makes sense to keep yum around for a few releases as a fallback. Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? I would expect puppet/chef to start using the library rather than direct access to the binary. And for ansible, I think the patch is quite simple, just add 2 lines. I guess we can start right now to get stuff merged. Yes, you can either use dnf's well documented API [1] or you can use the libraries beneath it. That's one of the advantages of dnf. Its individual components were moved to external libraries and can be used by anyone, as few projects can already testify. The last piece that is missing and being worked on is a library wrapping dnf software database. Thanks Jan [1] http://akozumpl.github.io/dnf/api.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 14:07:05, DJ Delorie wrote: Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. I'm sorry but at this point I feel I gotta ask: have you read my earlier replies? Nothing will change for you, the yum command will still exist for a few more Fedora releases, just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
On 11. 6. 2014 at 18:55:37, Miloslav Trmač wrote: 2014-06-11 16:08 GMT+02:00 drago01 drag...@gmail.com: That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one. Precisely; such splits are always incredibly painful for everyone. Yes, it would require a more detailed contingency planning, but having upgraded and new systems use a different package manager by the same command name and the same scripts would be a troubleshooting nightmare. We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
On Thu, Jun 12, 2014 at 10:03 AM, Jan Zelený jzel...@redhat.com wrote: On 11. 6. 2014 at 18:55:37, Miloslav Trmač wrote: 2014-06-11 16:08 GMT+02:00 drago01 drag...@gmail.com: That makes no sense. First of all if it obsoletes yum it will get pulled in during upgrades and imo it *should*. We don't really want to end up in a situation where half the users are using the default packing tool while the other half uses the old one. Precisely; such splits are always incredibly painful for everyone. Yes, it would require a more detailed contingency planning, but having upgraded and new systems use a different package manager by the same command name and the same scripts would be a troubleshooting nightmare. We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders. Well having user that upgrade have a different package manager then those who install new is not only not perfect but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand. -- 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: F21 System Wide Change: Fedora 21 Make 4.0 Update
On Thu, Jun 12, 2014 at 12:50 AM, Omair Majid oma...@redhat.com wrote: * Jaroslav Reznik jrez...@redhat.com [2014-04-14 08:32]: = Proposed System Wide Change: Fedora 21 Make 4.0 Update = https://fedoraproject.org/wiki/Changes/F21Make40 == Detailed Description == The purpose of this update is to synchronize Fedora with the most recent Make release. The contingency for this was supposed to trigger at the Mass Rebuild. However, koji tells me that the first time Make 4.0 was built in rawhide was during the Mass Rebuild [1] :( And of course, some of the changes in Make broke other programs. OpenJDK 8, for example, currently fails to build because of this. It built for the mass rebuild (because make was not built until that point) but fails now. What's the plan here? What fix do you propose for the Openjdk8 side of the problem? If there's a number of packages that need to be rebuilt it'll need to involve rel-eng and so I suggest if that's a course action a rel-eng ticket with the make4 owners cc:ed, hopefully the feature owners will pipe up here with a solution. 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: F22 System Wide Change: Replace Yum With DNF
On 06/11/2014 06:13 PM, Pierre-Yves Chibon wrote: If the idea is interesting it does imply that each person having scripts depending on yum has to: * s/yum/yum-legacy/ - Deploy to prod and run as before * s/yum-legacy/dnf/ - Test and ensure it has a consistent behavior w/ yum (that the script is not using any of the deprecated options, that there is no some surprises in some weird corners) Nope. It means that once /usr/bin/yum become symlink (or wrapper) to dnf, then either: 1) nothing will change because dnf is mostly compatible will yum. I would say this will be behavior for majority of existing scripts. 2) your script use some corner case of yum and will become broken. And you either a) migrate immediately to DNF b) you (the-sysadmin) are lazy and put it on back-burner and do s/yum/yum-legacy/ and you have to do that work from a) anyway one year later. -- Miroslav Suchy, RHCE, RHCDS Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- 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: F22 System Wide Change: Replace Yum With DNF
Am 12.06.2014 10:51, schrieb Miroslav Suchý: b) you (the-sysadmin) are lazy and put it on back-burner and do s/yum/yum-legacy/ and you have to do that work from a) anyway one year later stop people calling lazy because they are not accepting replacements which are not drop-in Fedora would most likely not exist if the decades before Unix/Linux would have changed it's behavior every few months - the we rename and replace everything all few months and looking how to replace it in a way everybody takes notice of our work is a more or less new phenomenon, in the past developers where proud of keep interface stability and the CLI is a user interface you need to realize that if you pretend to build a operating system the goal using a operating system for users is to build their work on top of that and not play around with the operating system all the time by looking which things are replaced or got a new syntax 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
Metainfo files for addons/plugins/extensions that extend desktop applications
Recently I added the addon component type to AppStream[1] which is an XML standard that is used by Fedora and lots of other distros to create metadata for various software center applications such as GNOME Software and KDE's Apper. By creating a metainfo.xml for each plugin, these are then shown next to the main desktop application and allow the user to easily install extra components in the UI. This is obviously important for projects like eclipse and gedit, as without the extra packages (which don't show up in the application-centric software center) the standalone applications are not super useful. I've written a blog post[2] about what upstream software needs to do to integrate with the KDE and GNOME software centers, and I'd really appreciate any feedback and help at this stage. Ideally these files can be pushed upstream and then packaged like normal, or they can be shipped in the srpm file like I did for gedit-code-assistance (which is awaiting a new upstream release). I don't think many packages will be affected, but I didn't want to catch any packagers by surprise when new files start popping up. If you want to contact me, either reply here or grab me on IRC -- I'm hughsie on freenode and gimpnet. Thanks, Richard [1] http://www.freedesktop.org/software/appstream/docs/ [2] http://blogs.gnome.org/hughsie/2014/06/11/application-addons-in-gnome-software/ -- 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: Slipping F21
* Tomasz Torcz [11/06/2014 23:20] : So we won't get 5.20 in stable Fedora for a year? More or less (we don't have a schedule for F22 yet). Emmanuel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EMEA sponsorship program for Flock
Hi, the EMEA regional community decided yesterday to organize a small sponsorship program for EMEA contributors who would like to attend Flock 2014 that is going to take place in Prague on Aug 6-9 and haven't received (and will not receive) any sponsorship as speakers. The overall amount of money allocated to the program is $2000. The funding limit per contributor is $200. The number of sponsored people is not limited and we will satisfy funding requests until we hit the limit of $2000. Candidates that have been actively contributing to the Project in the last year and have some work agenda for Flock (meeting team mates, organizing a do session,...) will be given a priority. The program is funded from the EMEA budget and is intended for contributors from this region. Other regions are assessing their budget situation and might come up with a similar program for their contributors. If you'd like to ask for a sponsorship, please file a ticket in the EMEA trac [1], mention your recent contributions to the Project and reasons why you want to attend Flock, and specify how much money you need (remember the limit is $200). The deadline is June 24 (12am UTC). The EMEA community has delegated the decision making to FAmSCo, so FAmSCo will then pick the best candidates if there are more requests than the available funding. Jiri [1] https://fedorahosted.org/emea-swag-tracking/ -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
On Qua, 2014-06-11 at 23:36 +0200, Simone Caronni wrote: Hello, On 11 June 2014 19:11, Sérgio Basto ser...@serjux.com wrote: Hi, why not begin by a xserver rebase in copr ? Personally, because I don't feel like doing the work twice. But if someone else wants to, sure, go for it. I could do it, also think about do it for eclipse-swt , but my problem is I don't know what packages I have to update , is not just xorg-x11-server , have you a list what we should update for xorg-x11-server 15.x ? Isn't this a rebuild already? http://copr.fedoraproject.org/coprs/jujuxiii/testing-fc20/ http://copr-be.cloud.fedoraproject.org/results/jujuxiii/testing-fc20/fedora-20-x86_64/ it's a start , how is this jujuxiii ? looks like a Portuguese / Brazilian name ... Also, any chance to see this applied in the rebuild? https://bugzilla.redhat.com/show_bug.cgi?id=1084433 why isn't also add to copr of jujuxiii Thanks, --Simone Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
Of the ones I know about ...
avgtime
Written in the 'D' language which doesn't have support for ARM upstream.
grub2
ARM (32 bit) boots using u-boot. Aarch64 machines will boot using
grub2 (or is that grub2-efi? - you know better than I do :-)
hfsplus-tools
As discussed in this thread.
ocaml-cil
ocaml-gsl
There are mature 32 bit and 64 bit ARM native backends for the OCaml
compiler. I've worked on fixing some problems in both.
As for these two packages, CIL is actually fixed upstream, it just
needs to go into the Fedora package (see RHBZ#994968). GSL depends on
a C library that contains lots of x86 assembler, and so basically
won't work without a lot of porting which no one has done yet. There
is no BZ for this one, which there obviously should be.
root
Discussed on this thread already.
zfs-fuse
This is interesting because it's another package where libguestfs has
to %ifnarch %{arm} because the package is missing on ARM.
The reason it doesn't build is because this package uses an internal
library to provide atomic ops, and this library hasn't been ported to
ARM assembler (although there is a fallback path that uses
pthread_mutex(!)).
There is a BZ (RHBZ#996728) but it is not listed in the spec file.
So, two conclusions from this:
1) People are very bad at following policy here. The majority of the
packages that are marked ExcludeArch: arm are not in the tracker bug,
and most of those don't appear to have a bug filed at all.
2) The rate at which things are being fixed appears to be uninfluenced
by (1) - the number of bugs on the tracker may have increased, but the
number of packages actually excluded on ARM hasn't. This means that I
was grossly overestimating how many packages were broken. I made an
assertion without collecting accurate data first, and came to the wrong
conclusion. I apologise for that.
But also:
(3) Out of 15000 packages, only about 100 don't build on ARM, and
there are at most 50 missing bugs to fully comply with policy.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
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-arm] ExcludeArch tracker doesn't appear to be effective
I pulled git and have the following for ExclusiveArch: %{arm}:
joystick-support
While ARM doesn't have traditional joystick ports there have been some
people hook them up via GPIO and the like, enabled.
mcollective-qpid-plugin
perl-qpid
These were both legacy hangover from before qpid-gcc was fixed which
it has been for some time, now built on rawhide.
Both would likely not have been missed if there was appropriate BZ :-)
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: rfc: xserver rebase in F20 (was Re: Slipping F21)
Hi, On Qua, 2014-06-11 at 12:40 -0400, Adam Jackson wrote: On Wed, 2014-06-11 at 17:19 +0100, Sérgio Basto wrote: On Qua, 2014-06-11 at 12:09 -0400, Adam Jackson wrote: On Wed, 2014-06-11 at 17:56 +0200, drago01 wrote: Oh and xserver really .. I am the one that gets complaints from users that I can't fix because of our ancient x11 stack. I'm not intrinsically _opposed_ to rebasing X in F20. But it's not something we've done in any previous Fedora, and there are enough nvidia users out there that I'd want to be cautious about not breaking them more than we need to. If That Other Repo doesn't have a problem with getting builds lined up for nvidia/fglrx/whatever I'd be much more willing to do X rebases in existing releases. About the other repo rpmfusion, we just need some time on updates-testing to rebuild all drives , but I can ask for more details on rpmfusion mailing list . It's still tricky for things like the xwayland/gnome lockstep, but I think we know how to handle that. Hi, why not begin by a xserver rebase in copr ? Personally, because I don't feel like doing the work twice. But if someone else wants to, sure, go for it. the most important thing, for me, is understand what is your opinion (X team) about testing Xserver 1.15 , It is worth testing Xserver 1.15, or we should focus on 1.16 ? and sorry about my bad English Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders. Well having user that upgrade have a different package manager then those who install new is not only not perfect but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand. I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
Dne 11.6.2014 20:18, Felix Miata napsal(a): On 2014-06-11 14:07 (GMT-0400) DJ Delorie composed: Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. And in this particular case, the change is from a nice single finger word it's a two-hander, three finger. Eh ... Writing DNF by both hands and 3 fingers should be faster then typing YUM by single finger. But if you are using just pointer fingers of your both hands, then I can understand your point ;) BTW people who are using Czech or German keyboard layout would disagree with your argument anyway (hint: Y - Z). Vít -- 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: [ACTION REQUIRED] Retiring packages for Fedora 21 v2
python-gudev orphan, aledvink, sochotni Taken. Anyone who did miss the opportunity and still want it? Just let me know. -- 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: F22 System Wide Change: Replace Yum With DNF
Dne 11.6.2014 17:20, Jan Zelený napsal(a): On 11. 6. 2014 at 09:02:29, Rahul Sundaram wrote: Hi On Wed, Jun 11, 2014 at 8:52 AM, Matthew Miller wrote: This is kind of sentimental, and I think possibly Seth would not have liked to have a big deal made of it, but... I guess I'm going to anyway. I would like to keep the yum name in remembrance of his contributions. This also seems like the easiest path for all of the documentation, scripts, and user habits out there. I don't mind if the backend package is called dnf, but why not keep /usr/bin/yum as the primary command and just do the right thing, only warning on incompatible usage rather than nagging every time it is used? I strongly agree with this for practical reasons. There is no good rationale for moving away from yum as the name of the command except some of the command line changes which happened with yum anyway (download only was added and later removed for example) and one can warn specifically for those. The API changes are not something users care about. Also, dnf needs to drop all the legacy options before the transition (ie) pick erase or remove (preferably the latter) etc rather than retain all the compatibility options. The transition period is one reason why we want to keep the name dnf. We'd basically like to keep current yum around for users that have various scripts and stuff depending on it so they have some time to migrate to dnf. Also presenting dnf as a separate project forked from yum gives us better flexibility - for instance it's easier to drop obsoleted stuff because users don't have that high compatibility expectations. Thanks Jan I, for one, support this change as it was proposed. Vít -- 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-arm] ExcludeArch tracker doesn't appear to be effective
On Thu, Jun 12, 2014 at 11:58:55 +0100,
Peter Robinson pbrobin...@gmail.com wrote:
I pulled git and have the following for ExclusiveArch: %{arm}:
joystick-support
While ARM doesn't have traditional joystick ports there have been some
people hook them up via GPIO and the like, enabled.
Would these likely end up in joydev.ko or analog.ko? If there is some other
module that would be used, I'd like to add it to the list.
joystick-support just makes sure the modules used for joysticks and
gamepads are included (kernel-modules-extra is pulled in if needed) and
loaded during boot by default. In theory people could do this manually
without too much work, but the idea was to make it dead simple.
floppy-support works the same way, though currently floppy.ko is in
kernel-modules. (But I expect it to move to kernel-modules-extra
eventually.)
--
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: F22 System Wide Change: Replace Yum With DNF
On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote: We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders. Well having user that upgrade have a different package manager then those who install new is not only not perfect but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand. I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot. The arguments against renaming the command have been given. The dnf command should either be renamed back to yum, or there should be permanent backwards compatibility via a script, symlink, etc. There is NO good reason to force everyone to change scripts and command line habits just for the sake of changing the name of a command that is an almost 100% compatible evolution of the older command. Call the package dnf and obsolete the yum package, rename the old yum package to yum-legacy--fine. But please make yum install etc. still work with dnf. And if those arguments aren't convincing enough, the second best option, if you MUST change the name of the command, is to change it ONCE to something PERMANENT that never changes ever again. Something generic like package-manager or pkgman. A name like dnf isn't really helpful as part of the system command language API. It is obscure lore that contributes to making Linux harder to learn. (So is yum but that ship has sailed.) -- 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-arm] ExcludeArch tracker doesn't appear to be effective
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 12 Jun 2014 11:39:00 +0100 Richard W.M. Jones rjo...@redhat.com wrote: Of the ones I know about ... avgtime Written in the 'D' language which doesn't have support for ARM upstream. grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) its using grub2-efi the grub2 binary is grubaa64.efi -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmbW5AAoJEH7ltONmPFDRv7cP/R9/+ch7QZsmO78q+V995dlI Ftjduje5c3ZC3QYstMIns18wkvkrNmI5pSuQHMVVpajC2aRFAxuoXYXP8WLnjC2S fU++TrFz+n3j81Hed0dZ5w1KOjHHqaR8fpPOuo1zX8JVBLTF9JQkP8Oe54SCSIZz 1la/eF4TepQ+7QzYBjTqEsUySKL8UoNMcb3m4ZMSYq+s3Wi+MksVy30TDh+Dd+hK limHase5HTgjSA0pma8WjcS6NKYOrP9fmH45e5xl2wcTJodwxrop3IESW7QMdDZN ZqSOl0V3zRGDWGoVZt4CdhOB7RNK0jdpIL0SbNVHlr6k7m9+zmSNScwvEbv1oZ8N 41ZPtC4C2bjZwWJL3fgPLCWKZN2UqaFZZyDtWNt5b5UOM9K6FMlqMRTC4IIFDAV0 plO8TnnTcUmHhCHz8EXjG5EpSrjXLL0o0rSrxIRx2k3a1LS01Tq/IDWkbdivzpWK aR/MgjEjMXEzj1w1AnYekM+9lLWUKtKSrzrjlREvQTJObc8xcp7vKpX0oPT+MMu1 hjK03AVw+cp+NDzrCcRYbd75YPqqDOUa333XMC6oyw15rzqv4SCa5kGXVM0wkjAP 4aWSqYgm4IB2NM1jCjY90qs2N7SktaenDD/EMhbgRkKQ9903wXYOa2yqijWdaEK5 Y/eH465VG+fsCwoSuXVN =Sleu -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: F22 System Wide Change: Replace Yum With DNF
On Thu, Jun 12, 2014 at 10:01:22AM +0200, Jan Zelený wrote: On 11. 6. 2014 at 14:07:05, DJ Delorie wrote: Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. I'm sorry but at this point I feel I gotta ask: have you read my earlier replies? Nothing will change for you, the yum command will still exist for a few more Fedora releases, just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists. At least systemctl is generic unlike dnf. And systemctl is much more of a change from the way service works that it warranted a change of name. yum and dnf both work pretty much the same way from the user's perspective, so it is not a good argument to change the name. -- 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: F22 System Wide Change: Replace Yum With DNF
On Čt, 2014-06-12 at 10:09 -0400, Chuck Anderson wrote: On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote: We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders. Well having user that upgrade have a different package manager then those who install new is not only not perfect but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand. I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot. The arguments against renaming the command have been given. The dnf command should either be renamed back to yum, or there should be permanent backwards compatibility via a script, symlink, etc. There is NO good reason to force everyone to change scripts and command line habits just for the sake of changing the name of a command that is an almost 100% compatible evolution of the older command. Call the package dnf and obsolete the yum package, rename the old yum package to yum-legacy--fine. But please make yum install etc. still work with dnf. And if those arguments aren't convincing enough, the second best option, if you MUST change the name of the command, is to change it ONCE to something PERMANENT that never changes ever again. Something generic like package-manager or pkgman. A name like dnf isn't really helpful as part of the system command language API. It is obscure lore that contributes to making Linux harder to learn. (So is yum but that ship has sailed.) BTW repoquery --repoid=rawhide -f /usr/bin/pkg gives empty output so if you are really really sure that the command must be renamed, please use 'pkg'. But I vote for keeping yum symlink or script wrapper forever. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) -- 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: F22 System Wide Change: Replace Yum With DNF
On 12. 6. 2014 at 10:11:40, Chuck Anderson wrote: On Thu, Jun 12, 2014 at 10:01:22AM +0200, Jan Zelený wrote: On 11. 6. 2014 at 14:07:05, DJ Delorie wrote: Forcing the users to type a different command name to get exactly the same functionality only serves to annoy the user. I'm sorry but at this point I feel I gotta ask: have you read my earlier replies? Nothing will change for you, the yum command will still exist for a few more Fedora releases, just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists. At least systemctl is generic unlike dnf. And systemctl is much more of a change from the way service works that it warranted a change of name. yum and dnf both work pretty much the same way from the user's perspective, so it is not a good argument to change the name. Actually it is. The pretty much part is exactly the reason why to change the name. If we didn't, a ton of users who are not reading this conversation would start filing regression bugs. If we set their expectations right, warning them that yum is no more, they are far less likely to do so. Thanks Jan -- 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: F22 System Wide Change: Replace Yum With DNF
On 12. 6. 2014 at 10:09:13, Chuck Anderson wrote: On Thu, Jun 12, 2014 at 02:10:22PM +0200, Jan Zelený wrote: We are open to ideas. I think in this situation there is no perfect way how to satisfy everyone. We have thought about this for several months. Renaming dnf back to yum might seem like the best option at first (it was our original plan too) but when you carefully and deeply think about this, keeping dnf and yum separate is really the least painful choice. So far I haven't seen a single strong argument against it that would satisfy needs of all the involved stakeholders. Well having user that upgrade have a different package manager then those who install new is not only not perfect but a no go. Simple obsolete yum so that dnf gets pulled in on upgrades and have rename the yum package to yum-legacy or something and have users that want it for whatever reason install it by hand. I think this is is alignment with what I said before - yum and dnf will still stay separated and dnf is not renamed. So if there is no argument against your proposal, we might as well give it a shot. The arguments against renaming the command have been given. The dnf command should either be renamed back to yum, or there should be permanent backwards compatibility via a script, symlink, etc. There is NO good reason to force everyone to change scripts and command line habits just for the sake of changing the name of a command that is an almost 100% compatible evolution of the older command. Call the package dnf and obsolete the yum package, rename the old yum package to yum-legacy--fine. But please make yum install etc. still work with dnf. We are on the same page, thanks for your input. Jan -- 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: Review requests: netgen-mesher, tcl-togl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/2014 07:07 PM, Sandro Mani wrote: Hi, For the ongoing effort to package salome/code-aster, I need these two dependencies: - https://bugzilla.redhat.com/show_bug.cgi?id=1108395 - netgen-mesher - Somewhat complexish, autotools, mpi subpackages - https://bugzilla.redhat.com/show_bug.cgi?id=1108355 - tcl-togl - Easy review, tcl/tk packaging Happy to review in exchange. Thanks, Sandro Hi Sandro, I will review these packages. Best, Mukundan. - -- GPG key-ID: 00E8658D -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBCgAGBQJTmblQAAoJEIfjPv0A6GWNAjcP/19H8ybsgQ+ZQk/VwxUWJEfx vTz9gdS9G2OKCYB42LBCRbf6/6J9UGatieuykI7upUHnbSIpZR/9mW4s2uqGpgj3 fR2QXYArmbcK0ZQa9bTFw5LAX3/ZWvvVgsgI4yT+BrxzqjI/0zdwmoeuK8Cha085 fCsHTKywxeiBvbiI8Fc0GY5xkob2JYn669xOFf9lZ61h+QzdhuAmynDRyK2/SwpW sSpsZ3Z8I5UNYotn133xE8VtX+yLi3xR0TXCUfifKpP5aWRaUAQNXqS3e7dPFSfb uAB38tiT4rQv6vcnRQ/Zb16lx0TM0Pj6+1A5bFwxIsaypa6JW6nE7XG/slonnm1N hQ07pewsoyB9HVLpI3Ga34BkP/jJ4eEBNLqGcR4eBM97nz244e9Fz3CZr8uakG/M 9ZXZNsG0hV9ENepbA3dZGa9JLMrii6mgYXBptPLBdeVqeIjI7qEA3Vw+wXVPzNOL 5TM9yDsdfGwJchFPmgHm1SP37/NEfTisNrcqahzeURQPi/75F6GqinEhv1LbLsv2 3kragyImJVigVHlFRZlrR6yeWnn4RJYrTdvkJIA/NAF5wjG09fvnwN6wXV5YFclv 6Lwj2dgY0i85pkVvXywtRHiJ7ZXXiU8NnqtM7AjSfwUsnJy2+3f7yNh1h6HQtlsq Dn8ZLKZI9ENhcNJ6KGKC =JekE -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: F22 System Wide Change: Replace Yum With DNF
Am 12.06.2014 16:28, schrieb Jan Zelený: On 12. 6. 2014 at 10:11:40, Chuck Anderson wrote: At least systemctl is generic unlike dnf. And systemctl is much more of a change from the way service works that it warranted a change of name. yum and dnf both work pretty much the same way from the user's perspective, so it is not a good argument to change the name. Actually it is. The pretty much part is exactly the reason why to change the name. If we didn't, a ton of users who are not reading this conversation would start filing regression bugs. If we set their expectations right, warning them that yum is no more, they are far less likely to do so. wrong * you get that regression bugs anyways * the only thing what you are doing is spread confusion in case of set their expectations right * why was GNOME3 not renamed * why was KDE4 not renamed * why was Apache 2.4 not renamed the only expectation a user has is that behavior don't change and features / options are not removed and called 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: F22 System Wide Change: Replace Yum With DNF
Nothing will change for you, the yum command will still exist for a few more Fedora releases, Which only postpones the problem. just as the `service` command that was superseded by systemctl like 5 releases of Fedora ago exists. Which is currently annoying me, for the same reason. -- 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: F22 System Wide Change: Replace Yum With DNF
Hi On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote: We are on the same page, thanks for your input. I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user. The analogy to systemctl doesn't work because systemctl is part of a completely separate project that works very differently from service command while dnf is a experimental fork of yum with a few fairly minor differences in command line and configuration options. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Review requests: netgen-mesher, tcl-togl
On 12.06.2014 16:29, Mukundan Ragavan wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 06/11/2014 07:07 PM, Sandro Mani wrote: Hi, For the ongoing effort to package salome/code-aster, I need these two dependencies: - https://bugzilla.redhat.com/show_bug.cgi?id=1108395 - netgen-mesher - Somewhat complexish, autotools, mpi subpackages - https://bugzilla.redhat.com/show_bug.cgi?id=1108355 - tcl-togl - Easy review, tcl/tk packaging Happy to review in exchange. Thanks, Sandro Hi Sandro, I will review these packages. Thanks! Sandro -- 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: F22 System Wide Change: Replace Yum With DNF
2014-06-12 17:03 GMT+02:00 Rahul Sundaram methe...@gmail.com: On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote: We are on the same page, thanks for your input. I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user. There are not only two sides :) I don’t insist on dnf being a hidden “internal project name”; introducing new features (only?) under the dnf name is fine with me. I do object to planning to unnecessarily break the yum commands for which we actually have compatibility. Mirek -- 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: F22 System Wide Change: Replace Yum With DNF
I am +1 for keeping the 'yum' name for the new manager, if only for the connotation. Telling users/consumers/customers that yum is upgraded and awesome is much easier than telling them that yum has been replaced and that the new tool is awesome. Even something like 'yum4' would be preferable to a new acronym to learn. Thanks, Jamie Duncan, RHCE Senior Technical Account Manager Red Hat, Inc. jdun...@redhat.com w-804.343.6086 c-804.307.7079 tech support-888.GO.REDHAT - Original Message - From: Rahul Sundaram methe...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Thursday, June 12, 2014 11:03:35 AM Subject: Re: F22 System Wide Change: Replace Yum With DNF Hi On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote: We are on the same page, thanks for your input. I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user. The analogy to systemctl doesn't work because systemctl is part of a completely separate project that works very differently from service command while dnf is a experimental fork of yum with a few fairly minor differences in command line and configuration options. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- 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: F21 System Wide Change: Fedora 21 Make 4.0 Update
* Peter Robinson pbrobin...@gmail.com [2014-06-12 04:25]: On Thu, Jun 12, 2014 at 12:50 AM, Omair Majid oma...@redhat.com wrote: * Jaroslav Reznik jrez...@redhat.com [2014-04-14 08:32]: = Proposed System Wide Change: Fedora 21 Make 4.0 Update = https://fedoraproject.org/wiki/Changes/F21Make40 == Detailed Description == The purpose of this update is to synchronize Fedora with the most recent Make release. The contingency for this was supposed to trigger at the Mass Rebuild. However, koji tells me that the first time Make 4.0 was built in rawhide was during the Mass Rebuild [1] :( And of course, some of the changes in Make broke other programs. OpenJDK 8, for example, currently fails to build because of this. It built for the mass rebuild (because make was not built until that point) but fails now. What's the plan here? What fix do you propose for the Openjdk8 side of the problem? Turns out, OpenJDK 8 was rely on some weird edge case. I haven't looked into it yet, but there's a one-liner fix someone pointed me to [1], so OpenJDK 8 should be easy to fix. I am just surprised that a major change went in at such a surprising time (middle of mass rebuild). Thanks, Omair [1] http://icedtea.classpath.org/hg/icedtea8-forest/hotspot/rev/b4ea3a87f707 -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 -- 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: F22 System Wide Change: Replace Yum With DNF
On 12.6.2014 16:16, Miloslav Trmač wrote: 2014-06-12 9:30 GMT+02:00 Jan Zelený jzel...@redhat.com: It boils down to this: someone is going to be inconvenienced. I argue it's better to inconvenience the minority with special 'yum' needs by making them use the 'yum-old' alias, rather than inconveniencing the majority by making everyone switch their scripts and fingers to 'dnf'. As I said, we will have transition layer so using yum in your shell scripts will still work for a few more releases. A vast majority of users should not experience any inconveniences other than different output on the command line. … *now*, but *will be inconvenienced later* after those “a few more releases” when you are planning for the yum command to go away. The total breakage and total impact on users is the same, you are only arguing for a different timing that makes it seem like a smaller breakage. (And separately, I don’t buy the argument that this redirection-with-a-message is how users learn about the new tools. This way they only learn about the *most useless* part of the change, namely “that old thing the system used to do? It can do the same thing, but in addition you have to learn a new command to keep it working“. It doesn’t teach *the useful part*, “here are the new features and here’s how to use them at all.) I support people who are requesting yum name to stay with us forever. Please replace yum with dnf when yum-legacy is finally dropped. -- Petr^2 Spacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
5tFTw: Board Meeting, Rawhide Rebuilt, Firewall Debate, ARM 64, and DNF as Yum Replacement, plus RHEL7 Bonus Item (2014-06-10)
Reposted from http://fedoramagazine.org/5tftw-2014-06-10/. Fedora is a big project, and it’s hard to follow it all. This series highlights interesting happenings in five different areas every week. It isn’t comprehensive news coverage — just quick summaries with links to each. Here are the five things for June 10th, 2014 (and sorry for the posting delay): New FPL Board Meeting - We held the first public Fedora Project Board meeting of my new tenure as Fedora Project Leader yesterday, as an informal town-hall discussion. You can read the summary or full log. We’ll be holding these every two weeks. Usually, we’ll have an agenda based on decisions to be made or (as suggested in this discussion, actually) with representatives from different parts of the project talking about their area of Fedora. But when we don’t have a pre-planned schedule, we’ll do open floor like this for whatever people want to talk about. (In this week’s case, it’s largely this: Fedora QA could use your help!) * http://meetbot.fedoraproject.org/fedora-meeting/2014-06-09/board.2014-06-09-17.00.html * http://meetbot.fedoraproject.org/fedora-meeting/2014-06-09/board.2014-06-09-17.00.log.html * https://fedoraproject.org/wiki/QA/Join Rawhide Mass Rebuild Periodically, we do a “mass rebuild” of all of the packages in Rawhide, our development branch. This makes sure that all of the software uses the latest compilers and build macros. This is mostly an automated process, but sometimes some software does not rebuild successfully. If that software doesn’t get updated by its maintainers, and no one picks it up, it will eventually be dropped from the distribution. Fedora Release Engineer Dennis Gilmore posted a Fedora 21 Mass rebuild update, including a link to the packages which need work. If any of these are yours, please fix. Or if there’s something that you’re interested in that isn’t rebuilding, considerer helping by becoming a co-maintainer. (If you’re curious, the standard operating procedure followed for these rebuilds is available on the Fedora wiki at Mass Rebuild SOP.) * https://lists.fedoraproject.org/pipermail/devel/2014-June/199629.html * http://ausil.fedorapeople.org/f21-failures.html * http://fedoraproject.org/wiki/Mass_Rebuild_SOP Fedora Workstation and Firewalld In April, there was a large discussion over a proposal to drop the firewall by default from Fedora Workstaion. The basic argument was that the the current state of application integration with the firewall service FirewallD isn’t adequate to provide a good user experience, and that the security benefits aren’t really meaningful in actual practice. Others disagreed, and ultimately, Workstation designers and FirewallD developers met to figure out a solution. Developer Bastien Nocera summarizes the resulting plan, which includes additional automated testing, a new firewall zone, and adding network awareness to GNOME’s “sharing” controls. * https://lists.fedoraproject.org/pipermail/devel/2014-April/198041.html * http://fedoraproject.org/wiki/Workstation * https://fedoraproject.org/wiki/FirewallD * https://lists.fedoraproject.org/pipermail/desktop/2014-June/009862.html Update on 64-bit ARM and Fedora 21 -- Fedora contributor and ARM hacker Peter Robinson provides an aarch64 (arm64) on Fedora 21 update. Current ARM support in Fedora is 32-bit, and focused mostly on low-cost consumer devices. The new 64-bit “aarch64″ architecture promises an exciting future of low-cost, energy-efficient, high-density servers — the “hyperscale” datacenter. Peter says that progress is going nicely, with some porting work remaining particularly around support of newer langages like Go and server-side Javascript, but an overall status of “looking awesome”. * http://nullr0ute.com/2014/06/aarch64-arm64-on-fedora-21-update/ * http://golang.org/ * https://code.google.com/p/v8/ DNF Proposed for Fedora 22 (and user survey) DNF is an experimental package manager, similar to the current Yum. It’s *largely* a drop-in replacement, promising faster dependency-solving and (more critically) a new explicitly-defined API designed to make it easier to develop higher-level software like GUI tools an plugins. There was a great article in January on Linux Weekly News about a *previous* long discussion on DNF, and that’s recommended reading if you missed it before. But also, the DNF developers are asking for user feedback on Yum features missing in DNF, so please do register your feedback about what is important to you. And there is a feature proposal, not for the upcoming Fedora 21, but for next year’s Fedora 22, to replace the current Yum with DNF (possibly as “yum 4″). * http://dnf.baseurl.org/ * http://yum.baseurl.org/ * https://lwn.net/Articles/580223/ *
Re: F22 System Wide Change: Replace Yum With DNF
On Thu, 2014-06-12 at 17:13 +0200, Miloslav Trmač wrote: 2014-06-12 17:03 GMT+02:00 Rahul Sundaram methe...@gmail.com: On Thu, Jun 12, 2014 at 10:29 AM, Jan Zelený wrote: We are on the same page, thanks for your input. I don't think so. You are clearly arguing for a temporary compatibility wrapper but eventually forcing everyone to use dnf as the command. The other side is wanting yum to continue to remain the name for the command with yum-legacy for temporary transition. In otherwords, dnf is an internal project name and doesn't need to be exposed to the user. There are not only two sides :) I don’t insist on dnf being a hidden “internal project name”; introducing new features (only?) under the dnf name is fine with me. I do object to planning to unnecessarily break the yum commands for which we actually have compatibility. We can keep the yum symlink forever... I am for a clear break with dnf having its own name. Using yum as the name for dnf is just a lie to the user and is not helpful. Dnf is a completely different project and code base that just happens to be highly compatible with yum as a way to smooth the transition. That is perfectly fine, and not spreading lies is an excellent strategy to slowly educate users. The service - systemctl example is actually an excellent example of a smooth transition IMO, and should be followed. If you like yum you keep the compat package, if you hate it: dnf remove yum-compat and be happy. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Am 12.06.2014 17:41, schrieb Simo Sorce: We can keep the yum symlink forever... I am for a clear break with dnf having its own name. Using yum as the name for dnf is just a lie to the user it is not a lie DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM as said: otherwise you would have to find a new name for any major version with large changes of any piece of software (GNOME, KDE, Apache) frankly and as long there is no useful name call something DNF is not helpful because it has no meaning while YUM is widely known as * yet another update manager * yellowdog updater modified http://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified 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: [fedora-arm] ExcludeArch tracker doesn't appear to be effective
On Thu, Jun 12, 2014 at 11:39:00AM +0100, Richard W.M. Jones wrote: grub2 ARM (32 bit) boots using u-boot. Aarch64 machines will boot using grub2 (or is that grub2-efi? - you know better than I do :-) This one's purely excluded from 32-bit ARM. The source package is grub2 regardless of the firmware interface used. (3) Out of 15000 packages, only about 100 don't build on ARM, and there are at most 50 missing bugs to fully comply with policy. I didn't go through the list of FTBFS to figure out whether there are other cases, but yeah, the situation certainly isn't dreadful. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On Thu, 2014-06-12 at 17:54 +0200, Reindl Harald wrote: Am 12.06.2014 17:41, schrieb Simo Sorce: We can keep the yum symlink forever... I am for a clear break with dnf having its own name. Using yum as the name for dnf is just a lie to the user it is not a lie DNF is a fork of YUM and pretends to be compatible and if it finally replaces YUM it's just a new generation of YUM as said: otherwise you would have to find a new name for any major version with large changes of any piece of software (GNOME, KDE, Apache) frankly and as long there is no useful name call something DNF is not helpful because it has no meaning while YUM is widely known as * yet another update manager * yellowdog updater modified http://en.wikipedia.org/wiki/Yellowdog_Updater,_Modified I think that dnf is an unfortunate name change. DNF in almost all kinds of racing stands for Did Not Finish Regards, Les H -- 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: F22 System Wide Change: Replace Yum With DNF
Actually it is. The pretty much part is exactly the reason why to change the name. If we didn't, a ton of users who are not reading this conversation would start filing regression bugs. If we set their expectations right, warning them that yum is no more, they are far less likely to do so. The right way to handle this is the way that every other package handles it. Detect the no-longer-compatible option and tell the user that option is no longer available. That way, the only users who are ever inconvenienced are the few that are using the obsolete option. The wrong way to solve this is to inconvenience *every* user for the sake of the few who need it. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On Thu, Jun 12, 2014 at 10:09:13AM -0400, Chuck Anderson wrote: And if those arguments aren't convincing enough, the second best option, if you MUST change the name of the command, is to change it ONCE to something PERMANENT that never changes ever again. Something generic like package-manager or pkgman. Heh, apt-get. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- 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: F22 System Wide Change: Replace Yum With DNF
On Wed, Jun 11, 2014 at 11:37:15AM -0400, Chuck Anderson wrote: Have puppet, chef, ansible, salt, etc. been taught how to use dnf to install packages? I think it would be a shame to force all this software to do s/yum/dnf/ or to have to conditionally code for these differences based on OS release or the presense of yum vs. dnf. Why not just keep the command name the same with no nag message? Even harder to change: - 1s of users' brains - 1s of pages of web-based documentation and printed books Just leave the command as yum and redirect to dnf transparently. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- 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: Orphaning drgeo, drgeo-doc
On 2014-06-07 07:49, Jonathan Dieter wrote: I'm orphaning drgeo and drgeo-doc. I originally picked them up because I thought our school would use drgeo, but we haven't, so I'm letting it go. IMHO it would be nice if this could stay in, but I'm not a Fedora packager (yet? :-). drgeo did FTBFS in the latest rebuild, and will probably need some TLC to get it building again. FWIW, I just posted a patch for the FTBFS: https://bugzilla.redhat.com/show_bug.cgi?id=1037042#c2 If you decide to take this, please note that upstream has moved to a squeak VM image, and I haven't been able to find the source for it, so we're still on drgeo 1.x. TBH, I suspect we'll be stuck with 1.1.0 for the foreseeable future, but it still works. Yaakov Selkowitz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Replace Yum With DNF
Excuse me. To whom, or to where, should I write to request that dnf has a tools package like yum has. Yum-utils. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
What exactly is a bundled library? (was Re: apitrace, bundled libbacktrace)
On Tue, 2014-05-13 at 18:56 +0200, Sandro Mani wrote: Hi, apitrace 5.0 bundles libbacktrace, which looks like is living within the gcc sources. libbacktrace is not build as a shared library from the gcc sources, and not packaged. Is it feasible to build libbacktrace as a shared library and ship it in a corresponding package? Or should I rather go for a bundling exception request? So in writing a reply to this, I noticed the guidelines around this are actually fairly unclear and subject to interpretation. The section on this topic from https://fedoraproject.org/wiki/Packaging:Guidelines reads: Duplication of system libraries A package should not include or build against a local copy of a library that exists on a system. The package should be patched to use the system libraries. This prevents old bugs and security holes from living on after the core system libraries have been fixed. In this RPM packaging context, the definition of the term 'library' includes: compiled third party source code resulting in shared or static linkable files, interpreted third party source code such as Python, PHP and others. At this time JavaScript intended to be served to a web browser on another computer is specifically exempted from this but this will likely change in the future. Note that for C and C++ there's only one system in Fedora but for some other languages we have parallel stacks. For instance, python, python3, jython, and pypy are all implementations of the python language but they are separate interpreters with slightly different implementations of the language. Each stack is considered its own system and can each contain its own copy of a library. The thing that is particularly unclear there is the definition of a system (as in a library that exists on a system). The following paragraphs seem to imply that Fedora's stacks for languages/frameworks that implement some kind of shared library functionality are to be understood as systems in that context. This is still not made *entirely* clear, though, really. The page https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries has all sorts of rationale and process stuff, but still no clear definition of precisely what it is that constitutes a bundled library. Even more confusingly, https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries seems to have a rather different definition from that given on Packaging:Guidelines. It reads: (bundled libraries being defined as libraries which exist and are mantained independently, whether or not they are packaged separately for Fedora) to me, that seems fundamentally different from the definition that is somewhat unclearly implied on the Packaging:Guidelines page. Has this been considered before? Is there a superior definition somewhere, or an accepted interpretation which is consistent with both pages? Do we in fact need a section in Packaging:Guidelines and then two separate 'subsidiary' pages all on the topic of bundled libraries? Would it make more sense to combine all the details onto a single subsidiary page and have Packaging:Guidelines just have a very short sort of 'summary' and a link to that one subsidiary page? Would that reduce the likelihood of confusion? Thanks! I've seen several cases in the Real World where 'bundled' libraries that are not a part of the Fedora repositories were considered to be OK under the policy, which is a possible interpretation of the policy as given on Packaging:Guidelines, but doesn't really seem to be a possible interpretation of the policy as given on Packaging:Treatment_Of_Bundled_Libraries (as it explicitly states whether or not they are packaged separately for Fedora). This could have considerable implementations for webapps if it were interpreted strictly, I think. -- 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: Replace Yum With DNF
Hi David, Probably the best place to ask is on the dnf bugzilla: https://bugzilla.redhat.com/buglist.cgi?component=dnfproduct=Fedora Also, I've noted that there is an open bug about a specific yum-util ( https://bugzilla.redhat.com/show_bug.cgi?id=1048541). Fabio On Thu, Jun 12, 2014 at 11:11 PM, David dgbo...@gmail.com wrote: Excuse me. To whom, or to where, should I write to request that dnf has a tools package like yum has. Yum-utils. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Fabio Alessandro Locati Home: Segrate, Milan, Italy (CET/CEST) Phone: +39 348 2668873 MSN/Jabber/E-Mail: fabioloc...@gmail.com PGP Fingerprint: B1CD 2318 532D 57D6 56FA E409 64DE 5B09 C09A 145F Involved in: KDE, OpenStreetMap, Ubuntu, Wikimedia -- 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: Orphaning drgeo, drgeo-doc
On Thu, Jun 12, 2014 at 12:05 PM, Yaakov Selkowitz yselk...@redhat.com wrote: IMHO it would be nice if this could stay in, but I'm not a Fedora packager (yet? :-). FWIW, I just posted a patch for the FTBFS: I'll take over the 1.x pre-smalltalk package, incorporate your patch (thanks for that!), and otherwise try to maintain the package. If you become a Fedora packager, you are welcome to take it over from me. I'm also willing to try to package the 2.x (Smalltalk) version. Squeak is already in Fedora, and I have a little bit of Smalltalk experience, but no experience with packaging Smalltalk programs. Perhaps if I run into trouble I might be able to get some assistance from the Squeak package maintainer(s). Eric -- 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: Replace Yum With DNF
On 6/12/2014 5:53 PM, Fabio Alessandro Locati wrote: Hi David, Probably the best place to ask is on the dnf bugzilla: https://bugzilla.redhat.com/buglist.cgi?component=dnfproduct=Fedora Also, I've noted that there is an open bug about a specific yum-util (https://bugzilla.redhat.com/show_bug.cgi?id=1048541). Fabio On Thu, Jun 12, 2014 at 11:11 PM, David dgbo...@gmail.com mailto:dgbo...@gmail.com wrote: Excuse me. To whom, or to where, should I write to request that dnf has a tools package like yum has. Yum-utils. -- David -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Fabio Alessandro Locati That would be a 'RFE? I have never really understtod just how to enter one of those. But thank you Fabio. -- David -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Pic of girls for me ?
Sent from my iPhone -- 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: rfc: xserver rebase in F20 (was Re: Slipping F21)
On Qui, 2014-06-12 at 11:06 +0100, Sérgio Basto wrote: how is this jujuxiii ? I mean who is this jujuxiii ? -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
Matthew Miller wrote: On Wed, Jun 11, 2014 at 02:00:13AM +0200, Kevin Kofler wrote: That was overly critical of me and did nothing to actually further the discussion. I apologise. No need to apologize! It's just the truth: ARM is not ready to be a primary Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. There was no negative tone in Matthew Garrett's original message: If the Fedora/ARM community don't care about feature parity with x86, then we should just drop them back to secondary status. There was nothing impolite or insulting in there. It might be impopular with the ARM people, but it's still a valid point that had to be made, and shouldn't have been retracted. The decision to make ARM primary was a mistake, period. 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: Replace Yum With DNF
On Thu, Jun 12, 2014 at 18:17:01 -0400, David dgbo...@gmail.com wrote: On 6/12/2014 5:53 PM, Fabio Alessandro Locati wrote: That would be a 'RFE? I have never really understtod just how to enter one of those. Add the futurefeature keyword. That keeps the bug in rawhide after branches. -- 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: Current FTBFS packages (was Re: [ACTION REQUIRED] Retiring packages for Fedora 21)
On Fri, Jun 13, 2014 at 01:50:32AM +0200, Kevin Kofler wrote: Matthew Miller wrote: Kevin, I disagree. A positive tone to discussion is important even when speaking the truth. There was no negative tone in Matthew Garrett's original message: If the Fedora/ARM community don't care about feature parity with x86, then we should just drop them back to secondary status. There was nothing impolite or insulting in there. It might be impopular with the ARM people, but it's still a valid point that had to be made, and shouldn't have been retracted. In context, there was absolutely an impolite tone - it confounded there being no interest in making a single package work on ARM with the Fedora ARM community having no interest in feature parity. These are not actually the same thing, and the fact that I equated them was inappropriate. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Bug 1108093] perl-CPANPLUS-0.9152 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108093 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-CPANPLUS-0.91.52-2.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-06-12 02:46:38 -- 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=dXCqjf9dfma=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 Bug 1051108 depends on bug 1030572, which changed state. Bug 1030572 Summary: perl-PlRPC: not secure across trust boundaries https://bugzilla.redhat.com/show_bug.cgi?id=1030572 What|Removed |Added Status|VERIFIED|CLOSED Resolution|--- |CURRENTRELEASE -- 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=z1ksBeRfRya=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 Bug 1051106 depends on bug 1030572, which changed state. Bug 1030572 Summary: perl-PlRPC: not secure across trust boundaries https://bugzilla.redhat.com/show_bug.cgi?id=1030572 What|Removed |Added Status|VERIFIED|CLOSED Resolution|--- |CURRENTRELEASE -- 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=U8opyM3L9Ba=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 1108094] perl-Date-Easter-1.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108094 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-Date-Easter-1.21-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-Date-Easter-1.21-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=rMafii9Ldga=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 1108094] perl-Date-Easter-1.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108094 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-Date-Easter-1.21-1.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/perl-Date-Easter-1.21-1.el6 -- 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=aQVk2owKdga=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 1108091] perl-CGI-4.02 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108091 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-CGI-4.02-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-12 04:35:10 -- 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=4sl9rejWGRa=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 1108635] New: perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108635
Bug ID: 1108635
Summary: perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails
randomly
Product: Fedora
Version: rawhide
Component: perl-autobox-Core
Assignee: iarn...@gmail.com
Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: iarn...@gmail.com, perl-devel@lists.fedoraproject.org
perl-autobox-Core-1.24-5.fc21 fails to build in F21 and F20 due randomly
failing tests:
# Failed test at t/flip.t line 8.
# Structures begin differing at:
# $got-{bar} = '2'
# $expected-{bar} = '3'
# Failed test 'Returns hash in list context'
# at t/flip.t line 12.
# Structures begin differing at:
# $got-{bar} = '2'
# $expected-{bar} = '3'
# Looks like you failed 2 tests of 2.
t/flip.t .
Dubious, test returned 2 (wstat 512, 0x200)
Failed
This is caused by random hash key order probably.
--
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=Hf1uNKTicDa=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 1108635] perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108635 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|iarn...@gmail.com |ppi...@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=q9sUQeRVe6a=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 1108635] perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108635 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Version|rawhide |20 Fixed In Version||perl-autobox-Core-1.27-1.fc ||21 -- 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=cOqPxv5Jlxa=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 1108635] perl-autobox-Core-1.24-5.fc21 FTBFS: t/flip.t fails randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108635 --- Comment #1 from Fedora Update System upda...@fedoraproject.org --- perl-autobox-Core-1.27-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-autobox-Core-1.27-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=4BMCaaq3J9a=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 1108698] New: perl-Net-Jabber-2.0-23.fc21 FTBFS randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108698 Bug ID: 1108698 Summary: perl-Net-Jabber-2.0-23.fc21 FTBFS randomly Product: Fedora Version: rawhide Component: perl-Net-Jabber Assignee: psab...@redhat.com Reporter: ppi...@redhat.com QA Contact: extras...@fedoraproject.org CC: mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, psab...@redhat.com, xav...@bachelot.org External Bug ID: CPAN 40292 perl-Net-Jabber-2.0-23.fc21 fails a test randomly: # Failed test (t/query_time.t at line 58) # 'MET DST' # doesn't match '(?^:^\S+$)' # Looks like you failed 1 tests of 39. t/query_time.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed -- 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=18GMEJ35DUa=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 1108107] perl-Text-CSV_XS-1.09 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108107 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Text-CSV_XS-1.09-1.fc2 ||1 Resolution|--- |RAWHIDE Last Closed||2014-06-12 09:40:16 -- 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=yYrsVBPHkFa=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 1108739] New: perl-Crypt-GeneratePassword-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108739 Bug ID: 1108739 Summary: perl-Crypt-GeneratePassword-0.04 is available Product: Fedora Version: rawhide Component: perl-Crypt-GeneratePassword Keywords: FutureFeature, Triaged Assignee: msu...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: msu...@redhat.com, perl-devel@lists.fedoraproject.org Latest upstream release: 0.04 Current version/release in Fedora Rawhide: 0.03-28.fc21 URL: http://search.cpan.org/dist/Crypt-GeneratePassword/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=Gcuj9Pk5j0a=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 1108746] New: perl-NetAddr-IP-4.075 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108746 Bug ID: 1108746 Summary: perl-NetAddr-IP-4.075 is available Product: Fedora Version: rawhide Component: perl-NetAddr-IP Keywords: FutureFeature, Triaged Assignee: andr...@bawue.net Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: andr...@bawue.net, perl-devel@lists.fedoraproject.org Latest upstream release: 4.075 Current version/release in Fedora Rawhide: 4.073-2.fc21 URL: http://search.cpan.org/dist/NetAddr-IP/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=LdzZkRh2wAa=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 1108757] New: perl-Test-Harness-3.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108757 Bug ID: 1108757 Summary: perl-Test-Harness-3.32 is available Product: Fedora Version: rawhide Component: perl-Test-Harness Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 3.32 Current version/release in Fedora Rawhide: 3.31-1.fc21 URL: http://search.cpan.org/dist/Test-Harness/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=5DoeeDGspqa=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 1108760] New: perl-YAML-Tiny-1.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108760 Bug ID: 1108760 Summary: perl-YAML-Tiny-1.63 is available Product: Fedora Version: rawhide Component: perl-YAML-Tiny Keywords: FutureFeature, Triaged Assignee: st...@silug.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, psab...@redhat.com, st...@silug.org Latest upstream release: 1.63 Current version/release in Fedora Rawhide: 1.62-2.fc21 URL: http://search.cpan.org/dist/YAML-Tiny/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- 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=aJbjRq9MGCa=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 1108757] perl-Test-Harness-3.32 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108757 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Harness-3.32-1.fc ||21 Resolution|--- |RAWHIDE Last Closed||2014-06-12 10:35:21 -- 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=ICWAD9BMHGa=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 1108698] perl-Net-Jabber-2.0-23.fc21 FTBFS randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108698 --- Comment #1 from Petr Šabata psab...@redhat.com --- Created attachment 908180 -- https://bugzilla.redhat.com/attachment.cgi?id=908180action=edit Allow timezone abbreviations with spaces -- 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=VopchzdvuYa=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 1108698] perl-Net-Jabber-2.0-23.fc21 FTBFS randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108698 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Net-Jabber-2.0-24.fc21 Resolution|--- |RAWHIDE External Bug ID|CPAN 40292 | Last Closed||2014-06-12 10:44:42 -- 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=SQDN5u8vMUa=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 1108698] perl-Net-Jabber-2.0-23.fc21 FTBFS randomly
https://bugzilla.redhat.com/show_bug.cgi?id=1108698 Petr Šabata psab...@redhat.com changed: What|Removed |Added External Bug ID||CPAN 96404 -- 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=CwRLRWZBbpa=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 1108739] perl-Crypt-GeneratePassword-0.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108739 Miroslav Suchý msu...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |NEXTRELEASE Last Closed||2014-06-12 11:12:22 --- Comment #1 from Miroslav Suchý msu...@redhat.com --- Built in rawhide. -- 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=BfyXa3bQx6a=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 1106197] perl-SDL: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1106197 Yaakov Selkowitz yselk...@redhat.com changed: What|Removed |Added CC||yselk...@redhat.com --- Comment #4 from Yaakov Selkowitz yselk...@redhat.com --- FTBFS because some tests failed, but only on i686: t/gfx_imagefilter.t . Failed 7/8 subtests The x86_64 task in the same build did succeed, however. SDL_gfx itself, which this test relies upon, uses MMX code only on ix86. I tried perl-SDL again using a mock build of SDL_gfx with an unconditional --disable-mmx and the testsuite passed. So, ultimately this is an issue with SDL_gfx, or possibly even with GCC; the easiest workaround for the sake of the rebuild is to disable MMX even on ix86 in the former. -- 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=Kx61vR4YdRa=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 1106197] perl-SDL: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1106197 Yaakov Selkowitz yselk...@redhat.com changed: What|Removed |Added CC||matth...@saou.eu --- Comment #5 from Yaakov Selkowitz yselk...@redhat.com --- CCing SDL_gfx owner. -- 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=6nP2xBpXWva=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 1108746] perl-NetAddr-IP-4.075 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108746 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED CC||p...@city-fan.org Fixed In Version||perl-NetAddr-IP-4.075-1.fc2 ||1 Resolution|--- |RAWHIDE Assignee|andr...@bawue.net |p...@city-fan.org Last Closed||2014-06-12 16:45:24 -- 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=nqzeYCG7nma=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 1108760] perl-YAML-Tiny-1.63 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108760 Paul Howarth p...@city-fan.org changed: What|Removed |Added Status|NEW |CLOSED CC||p...@city-fan.org Fixed In Version||perl-YAML-Tiny-1.63-1.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-12 16:46:27 -- 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=o8oDmwN3CWa=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 1108094] perl-Date-Easter-1.21 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1108094 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- Package perl-Date-Easter-1.21-1.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing perl-Date-Easter-1.21-1.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1637/perl-Date-Easter-1.21-1.el6 then log in and leave karma (feedback). -- 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=Dx4CnMvspNa=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 1000038] Please build perl-Net-Twitter for EPEL
https://bugzilla.redhat.com/show_bug.cgi?id=138 Julian C. Dunn jd...@aquezada.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |WONTFIX Last Closed||2014-06-12 20:50:07 --- Comment #5 from Julian C. Dunn jd...@aquezada.com --- Based on this feedback about the upstream deps I am going to mark this as WONTFIX. -- 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=tQESLQPEewa=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
