EPEL epel beta report: 20140613 changes
Compose started at Fri Jun 13 08:15:02 UTC 2014 New package: ctstream-19-2.el7 Get URLs of Czech Television video streams New package: python-click-2.0-2.el7 A simple wrapper around optparse for powerful command line utilities Updated Packages: canl-java-2.1.0-3.el7 - * Wed Jun 11 2014 Mattias Ellert mattias.ell...@fysast.uu.se - 2.1.0-3 - Fix test that fails when using OpenJDK 1.8 (patch from upstream git) * Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 2.1.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild koji-1.9.0-3.el7 * Thu Jun 12 2014 Dennis Gilmore den...@ausil.us - 1.9.0-3 - add patch to move builder workdir to /var/tmp - add support for making raw.xz images * Sun Jun 08 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.9.0-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild mingw-qt5-qttools-5.3.0-3.el7 - python-django-evolution-0.7.2-3.el7 --- * Thu Jun 12 2014 Stephen Gallagher sgall...@redhat.com 1:0.7.2-3 - Bump epoch to handle upgrades from Fedora 20 properly * Sat Jun 07 2014 Fedora Release Engineering rel-...@lists.fedoraproject.org - 0.7.2-2 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild Summary: Added Packages: 2 Removed Packages: 0 Modified Packages: 4 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 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 28 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1414/gajim-0.14.4-4.el6 23 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 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 8 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1572/chkrootkit-0.49-9.el6 4 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 1 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 exim-4.72-5.el6 Details about builds: exim-4.72-5.el6 (FEDORA-EPEL-2014-1644) The exim mail transfer agent Update Information: Rebuilt to show correct version of OpenSSL (exim -bV) ChangeLog: * Fri Jun 13 2014 Jaroslav Škarvada jskar...@redhat.com - 4.72-5 - Rebuilt to show correct version of OpenSSL (exim -bV) - Fixed bogus dates in changelog (best effort) ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: Replace Yum With DNF
On 12. 6. 2014 at 17:11:14, David wrote: Excuse me. To whom, or to where, should I write to request that dnf has a tools package like yum has. Yum-utils. We definitely encourage you to file the RFE, but if you want to discuss it upfront, feel free to ping us on IRC, we hang out on #yum @ FreeNode (although today and the next week might be a bit problematic because two out of three developers are afk). Also note that some of the things from yum-utils are already ported to dnf and we definitely plan to take a look at the rest so filing the RFE might be a bit redundant. 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:54:45, DJ Delorie wrote: 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. I'm sorry you feel this way. Most of the people I talked to are quite happy how this transition was handled. That's why I consider it a good strategy for dnf as well. If you have any other suggestions other than keeping the name, we will be open to consider them. 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 11:41:52, Simo Sorce wrote: 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... Definitely, we do no insist on removing it. I am perfectly fine with removing it some time far in the future when nobody uses it any more. 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
Am 13.06.2014 10:01, schrieb Jan Zelený: On 12. 6. 2014 at 11:41:52, Simo Sorce wrote: We can keep the yum symlink forever... Definitely, we do no insist on removing it. I am perfectly fine with removing it some time far in the future when nobody uses it any more one said forever, i am not a native english speaker but IMHO that word has a clear definition * do not insist on removing it * removing it some time far in the future you can have one of them :-) i have not heard any valid reason to call a software DNF instead just the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to Did Not Finish beause it has no senseful meaning and so finally you can call it yum-ng and in the history ng-replacements did not change binary names 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
On 12. 6. 2014 at 16:16:13, 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. I think we are getting way, *way* ahead of ourselves. You are talking about the distant future as if it was to happen tomorrow. If users will want the command to stay here forever, it might as well stay here forever. This should *not* be the topic of the day, as it is currently irrelevant. (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.) For your information, Ales does terrific job getting the knowledge of new features to public. DNF's documentation is one of the best I have ever seen, especially considering that the project is very much WIP. Blog posts are published almost every week, we regularly announce the interesting stuff on f- d-l, f-u-l and yum-devel list. If you have any ideas how to make the situation even better and actually make users care, please do share them with us! 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 June 2014 16:54, Reindl Harald h.rei...@thelounge.net wrote: 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 Just do a side-by-side comparison of the code bases. Calling dnf yum would be a lie indeed. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
Am 13.06.2014 10:15, schrieb Richard Hughes: On 12 June 2014 16:54, Reindl Harald h.rei...@thelounge.net wrote: 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 Just do a side-by-side comparison of the code bases. Calling dnf yum would be a lie indeed and why do you call GNOME3 then GNOME? 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
Am 13.06.2014 10:13, schrieb Jan Zelený: On 12. 6. 2014 at 16:16:13, Miloslav Trmač wrote: … *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. I think we are getting way, *way* ahead of ourselves. You are talking about the distant future as if it was to happen tomorrow. If users will want the command to stay here forever, it might as well stay here forever. This should *not* be the topic of the day, as it is currently irrelevant smart decisions are made by think about the distant future to prevent mistakes and excuses like if i only had known that i would have... 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
On 13. 6. 2014 at 10:09:48, Reindl Harald wrote: Am 13.06.2014 10:01, schrieb Jan Zelený: On 12. 6. 2014 at 11:41:52, Simo Sorce wrote: We can keep the yum symlink forever... Definitely, we do no insist on removing it. I am perfectly fine with removing it some time far in the future when nobody uses it any more one said forever, i am not a native english speaker but IMHO that word has a clear definition * do not insist on removing it * removing it some time far in the future you can have one of them :-) Please, don't nitpick, it's not cool. What I meant is to maybe remove it when there is a general consensus it should be removed. Period, end of story. i have not heard any valid reason to call a software DNF instead just the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to Did Not Finish beause it has no senseful meaning and so finally you can call it yum-ng and in the history ng-replacements did not change binary names I have explained the reason on multiple occasions. If you volunteer to do the bug cleanup regularly and to explain users on daily basis that dnf is actually different from yum and they should not consider changes in behavior regressions, I will think about this some more (no promises). But fair warning, this effort will cost you about an hour of your time every single day. This is the last reply to you on this matter, thanks for understanding. 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
Headsup: New soname changing SDL_gfx build coming to rawhide
Hi, Upstream SDL_gfx has a new 2.0.25 release out for a while now. Since Fedora is supposed to be First it is time to upgrade to it. Unfortunately this release bumps the soname, so all deps need to be rebuild. I'll start rebuilds of all the affected packages myself, so unless the rebuild fails on your package no action is needed from your side. Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
2014-06-13 10:20 GMT+02:00 Jan Zelený jzel...@redhat.com: On 13. 6. 2014 at 10:09:48, Reindl Harald wrote: Am 13.06.2014 10:01, schrieb Jan Zelený: i have not heard any valid reason to call a software DNF instead just the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to Did Not Finish beause it has no senseful meaning and so finally you can call it yum-ng and in the history ng-replacements did not change binary names I have explained the reason on multiple occasions. If you volunteer to do the bug cleanup regularly and to explain users on daily basis that dnf is actually different from yum and they should not consider changes in behavior regressions, I will think about this some more (no promises). But fair warning, this effort will cost you about an hour of your time every single day. So not wanting users to complain about “yum” no longer having some features is the only reason for dropping the yum name I have seen in this thread (also called “setting expectations”); have I missed other reasons? If this is *the* reason, and you simultaneously propose to *keep* the “yum” name for the forseeable future, i.e. for the *entire time users are likely to complain*, how do you expect to get the benefit? AFAICS those bugs will get filed and will have to be handled, so “setting expectations” will not help your team’s workload at all. What am I missing? 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: Replace Yum With DNF
It alredy has, it is called dnf-plugins-core all tools in dnf is implemented as plugins there is extending the dnf command line Tim 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 -- 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
It alredy has, it is called dnf-plugins-core all tools in dnf is implemented as plugins there is extending the dnf command line Is there a migration for users and developers document? A page with yum commands on the left and corresponding commands with dnf on the right. Including developer things like scripts from yum-utils (yum-builddep etc). Thanks. -- Later, Lukas lzap Zapletal irc: lzap #theforeman -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Fedora Base Design Working Group (2014-06-06) meeting minutes and logs
Quick recap of last weeks meeting: - Dropping the merge reviews from the agenda, will give an update once thats done - Quick update that there's progress on the help side for our efforts Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-06-06/fedora_base_design_working_group.2014-06-06-15.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-06-06/fedora_base_design_working_group.2014-06-06-15.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-06-06/fedora_base_design_working_group.2014-06-06-15.00.log.html Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Base] Base Design WG agenda meeting 13 June 2014 15:00 UTC on #fedora-meeting
Agenda: - Bill announced his departure from the WG, discussion about how we proceed. - Open floor - FYI: pknirsch on PTO next Friday Thanks regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Manager Core Services| Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Wankelstrasse 5 | Web: http://www.redhat.com/ D-70563 Stuttgart, Germany -- 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: [Base] Base Design WG agenda meeting 13 June 2014 15:00 UTC on #fedora-meeting
On Fri, Jun 13, 2014 at 8:37 AM, Phil Knirsch pknir...@redhat.com wrote: Agenda: - Bill announced his departure from the WG, discussion about how we proceed. - Open floor - FYI: pknirsch on PTO next Friday I'll be unable to attend. This is becoming a trend unfortunately and given it's been a while since we've done an interest check, it might be better for me to also step down from the WG. josh -- 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/13/2014 2:44 AM, Jan Zelený wrote: On 12. 6. 2014 at 17:11:14, David wrote: Excuse me. To whom, or to where, should I write to request that dnf has a tools package like yum has. Yum-utils. We definitely encourage you to file the RFE, but if you want to discuss it upfront, feel free to ping us on IRC, we hang out on #yum @ FreeNode (although today and the next week might be a bit problematic because two out of three developers are afk). Also note that some of the things from yum-utils are already ported to dnf and we definitely plan to take a look at the rest so filing the RFE might be a bit redundant. Thanks Jan Thank you. That was the answer I was hoping for here. As I said elsewhere in this thread I don't belong here. I am not a dev or a programer. I don't write code. Just a user. Unless dnf does not 'crash and burn' like YUM does from time to time the one YUM utility I would miss the most is 'package-cleanup --dupes'. Clean the duplicate entries in the database. -- 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
Re: Replace Yum With DNF
On Fri, Jun 13, 2014 at 2:30 PM, Lukas Zapletal l...@redhat.com wrote: Is there a migration for users and developers document? A page with yum commands on the left and corresponding commands with dnf on the right. Including developer things like scripts from yum-utils (yum-builddep etc). Thanks. You can check the docs for dnf-plugins-core http://dnf-plugins-core.readthedocs.org/en/latest/index.html If you are missing something, then make a bugzilla report against dnf-plugins-core, with a usecase for the tool your are missing. Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On 13. 6. 2014 at 11:36:25, Miloslav Trmač wrote: 2014-06-13 10:20 GMT+02:00 Jan Zelený jzel...@redhat.com: On 13. 6. 2014 at 10:09:48, Reindl Harald wrote: Am 13.06.2014 10:01, schrieb Jan Zelený: i have not heard any valid reason to call a software DNF instead just the next major version of YUM which is millions of times mentioned and well known everywhere - *forget* DNF as name - you won't revert the fact that everybody translates it to Did Not Finish beause it has no senseful meaning and so finally you can call it yum-ng and in the history ng-replacements did not change binary names I have explained the reason on multiple occasions. If you volunteer to do the bug cleanup regularly and to explain users on daily basis that dnf is actually different from yum and they should not consider changes in behavior regressions, I will think about this some more (no promises). But fair warning, this effort will cost you about an hour of your time every single day. So not wanting users to complain about “yum” no longer having some features is the only reason for dropping the yum name I have seen in this thread (also called “setting expectations”); have I missed other reasons? No, there is not. But I think you misunderstood the reason, although not by much. The fact is that dnf *is* different project than yum, let's not try to mask it. The vast majority of code base is different ( 85% for sure), its architecture is different, the community is different, the entire nature of the project is different. And the fact that its CLI interface tries to be as compatible as possible with yum doesn't change any of this. That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. If you want some more reasons, consider that the Python API might be different in dnf compared to yum and the configuration is definitely different: $ man yum.conf | wc -l 872 $ man dnf.conf | wc -l 138 If this is *the* reason, and you simultaneously propose to *keep* the “yum” name for the forseeable future, i.e. for the *entire time users are likely to complain*, how do you expect to get the benefit? AFAICS those bugs will get filed and will have to be handled, so “setting expectations” will not help your team’s workload at all. I wonder now, would it be better if we just dropped the yum command entirely? 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
Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? 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
On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. -- 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 13. 6. 2014 at 14:30:06, Lukas Zapletal wrote: It alredy has, it is called dnf-plugins-core all tools in dnf is implemented as plugins there is extending the dnf command line Is there a migration for users and developers document? A page with yum commands on the left and corresponding commands with dnf on the right. Including developer things like scripts from yum-utils (yum-builddep etc). This might be something you are looking for, although it includes just the changes that we already know are going to stay: http://akozumpl.github.io/dnf/cli_vs_yum.html HTH 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 13.6.2014 14:58, Reindl Harald wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do. Look at tradition of BIND: - BIND 4 was the original version (AFAIK) - BIND 8 was complete re-write of v4 - BIND 9 was complete re-write of v8 - BIND 10 was another attempt to completely re-write it ... Also, GNOME 3 and KDE 4 were mentioned several times. IMHO keeping almost-compatible command yum forever is priceless. Re-training all users to use different command is way more intrusive than simple fact that some options are missing in later version of software. Users have to deal with it anyway because 100 % backwards compatibility is often just an illusion. -- 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
Re: F22 System Wide Change: Replace Yum With DNF
Am 13.06.2014 15:03, schrieb drago01: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... close your eyes for 2 seconds to face how that bothers the user which is the bigot justification for the rename do you seriously explain me it's wrong that Linux still is called Linux or even that the implementation of 3.15 has anything common with Linux 1.0? Horses worked too but at some point we decided that cars work better and moved on that's childish a horse and a car are completly different things yum and dnf are not 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
On Fri, 2014-06-13 at 15:15 +0200, Reindl Harald wrote: Am 13.06.2014 15:03, schrieb drago01: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... close your eyes for 2 seconds to face how that bothers the user which is the bigot justification for the rename do you seriously explain me it's wrong that Linux still is called Linux or even that the implementation of 3.15 has anything common with Linux 1.0? Horses worked too but at some point we decided that cars work better and moved on that's childish a horse and a car are completly different things yum and dnf are not I think you are failing to undertstand the concept of perspective. The example is actually perfectly fitting. Why do you care if your transport is a horse or a car ? You should just call it tranmsport, right ? Anyway I think we should stop with this bikeshedding. The people write the code decided to call it DNF, and it is their right to do so, it is their project and they decided they want a new identity to go with it. To help the transition they are making it so that if you call yum it still works, and this should keep old cranky users happy. Be happy like that. 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
On Fri, 2014-06-13 at 14:53 +0200, Jan Zelený wrote: So not wanting users to complain about “yum” no longer having some features is the only reason for dropping the yum name I have seen in this thread (also called “setting expectations”); have I missed other reasons? No, there is not. But I think you misunderstood the reason, although not by much. The fact is that dnf *is* different project than yum, let's not try to mask it. The vast majority of code base is different ( 85% for sure), its architecture is different, the community is different, the entire nature of the project is different. And the fact that its CLI interface tries to be as compatible as possible with yum doesn't change any of this. I understand that you want to rename the project to show that it is a new thing, but do users of yum really care about these facts? Do as a user you really care if bind 9 was a total rewrite of bind 8? I believe you overestimate how much users of software care about the inner workings. That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. I again think you overestimate what users think of software. They don't think of yum as a particular code-base. Yum is the tool, like hammer is the tool. If you replace a hammer by a new redesigned hammer, it is still a hammer even if not 100% identical. regards, Nikos -- 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 Fri, Jun 13, 2014 at 9:33 AM, Simo Sorce wrote: I think you are failing to understand the concept of perspective. I think there is a difference in perspectives rather than lack of understanding. You are looking at it from a developer perspective - their project, let them do whatever they like but changing the name of a package manager is a extremely intrusive change for all users and commercially supported customers of RHEL down the line and the ripple effects are enormous. We are talking about a ton of documentation that needs to be updated etc. This change shouldn't be done without very careful deliberation and substantial justification. The API changes or code being rewritten isn't something that users care about at all. Some options being changed MAY cause some bug reports isn't enough of a reason to do this IMO. The notion that such bug reports will consume one hour every day for the development team is just a wild speculation. FWIW, I will volunteer to explain to users that this is a different project that choose to use the same name in all such bug reports. Please feel free to reassign them to me. Regards 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: F22 System Wide Change: Replace Yum With DNF
On Fri, Jun 13, 2014 at 09:38:40AM +0200, Jan Zelený wrote: On 12. 6. 2014 at 10:54:45, DJ Delorie wrote: 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. I'm sorry you feel this way. Most of the people I talked to are quite happy how this transition was handled. That's why I consider it a good strategy for dnf as well. If you have any other suggestions other than keeping the name, we will be open to consider them. The command name doesn't have to match the project name. E.g. just look at the ImageMagick package--there are tons of generic command names that don't mention ImageMagick (or any abbreviation thereof) in their names: rpm -ql ImageMagick|grep bin /usr/bin/animate /usr/bin/compare /usr/bin/composite /usr/bin/conjure /usr/bin/convert /usr/bin/display /usr/bin/identify /usr/bin/import /usr/bin/mogrify /usr/bin/montage /usr/bin/stream So I propose we keep calling the project DNF and the package dnf, but start the transition to a generic command name for the tool that installs, removes, and updates packages. I propose that this command name be called pkg. We can keep backwards compatibility to both the yum command name and the dnf command name indefinitely. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Non-responsive maintainer: Deji Akingunola (fas: deji)
Hi, I've filed this bug [1] in scotch nearly one month ago, the issue being that the scotch libraries are under-linked and have undefined symbols. A tentative patch is attached in the BZ. Since this is a blocker for the salome packaging, I'd like to see this resolved. Attempts to contact deji (both via bugzilla as well as as directly via email) have failed. Anyone knows how to reach him? Thanks, Sandro [1] https://bugzilla.redhat.com/show_bug.cgi?id=1098680 -- 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/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. Regards, Steve -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On Fri, Jun 13, 2014 at 4:39 PM, Steve Clark scl...@netwolves.com wrote: On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. Well I replied to his general statements about developers not understanding simple facts ... that aside ... it fits pretty well the horse (yum) is slower so takes longer to get the job done as the car (dnf) ;) -- 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 13.06.2014 16:49, schrieb drago01: On Fri, Jun 13, 2014 at 4:39 PM, Steve Clark scl...@netwolves.com wrote: On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. Well I replied to his general statements about developers not understanding simple facts ... that aside ... then the next time quote that what you reply to instead strip it out and stop talking about statements and facts because what you refer to was the user expects that anyways if you replace something he did not asked for replace it and what just worked for him, why do so many developers not understand that simple fact? it let you not look smarter if you try to drive a discussion in a specific direction by selective quoting and refer to things nobody but you knows you are refer to the argumentation the whole thread is bigot because as long it's opportune to support the own viewpoint the reason for the rename is because users expectations but if someone makes clear that it's wrong than the same people switch their argumentation within seconds to it's the developers decision bad attitude - someone should decide if he cares more for users and thousands of documentations, howtos and books or if he don't care for the users - not change his position all the time it fits pretty well the horse (yum) is slower so takes longer to get the job done as the car (dnf) ;) well, hopefully it does not fit the same way if it needs to drive offside a nice road in context of software: stability i am tired hear people talking about milliseconds of boot-performance and what update tool is slightly faster here and there because i never met anybody who is booting and upgrading his system 365/24/7 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
On 06/13/2014 11:01 AM, Reindl Harald wrote: well, hopefully it does not fit the same way if it needs to drive offside a nice road in context of software: stability i am tired hear people talking about milliseconds of boot-performance and what update tool is slightly faster here and there because i never met anybody who is booting and upgrading his system 365/24/7 +1 -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F22 System Wide Change: Replace Yum With DNF
On Fri, Jun 13, 2014 at 5:01 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 16:49, schrieb drago01: On Fri, Jun 13, 2014 at 4:39 PM, Steve Clark scl...@netwolves.com wrote: On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. Well I replied to his general statements about developers not understanding simple facts ... that aside ... then the next time quote that what you reply to instead strip it out and stop talking about statements and facts because what you refer to was the user expects that anyways if you replace something he did not asked for replace it and what just worked for him, why do so many developers not understand that simple fact? it let you not look smarter if you try to drive a discussion in a specific direction by selective quoting and refer to things nobody but you knows you are refer to That line was not supposed to get removed ... that happened while rewording the mail. Sorry for the incomplete quote. the argumentation the whole thread is bigot because as long it's opportune to support the own viewpoint the reason for the rename is because users expectations but if someone makes clear that it's wrong than the same people switch their argumentation within seconds to it's the developers decision Have you seen my other mails in the thread? I actually do agree that the command should be just called yum. bad attitude - someone should decide if he cares more for users and thousands of documentations, howtos and books or if he don't care for the users - not change his position all the time it fits pretty well the horse (yum) is slower so takes longer to get the job done as the car (dnf) ;) well, hopefully it does not fit the same way if it needs to drive offside a nice road in context of software: stability Yeah there are ways to solve that (testing and fixing bugs during the development phase i.e now). But we should not stop progress because what we have works ... we don't work on Fedora to keep things as is we want to improve what we have. (Just to be clear again that has nothing to do with the *name* of the things we just should not live in the past forever because something works). -- 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 13.06.2014 17:14, schrieb drago01: But we should not stop progress because what we have works ... we don't work on Fedora to keep things as is we want to improve what we have. (Just to be clear again that has nothing to do with the *name* of the things we just should not live in the past forever because something works) a never said anything other *but* whatever is changed - the impact to the users has to be minimized wherever it is possible and in doubt works is the better state than new but don't work here and there progress for me is things get better not only change and i go so far that if you manage to make things better but chnage the behavior for users where is no really hard need to do so the bad impact rubs all the optimizing and things which got better away polish a codebase, make it faster and so on should be completly invisible for the enduser and a good developer don't need a hard impact on the users side to let him feel that the developer did some work - the good developer knows his work was fine if there is no feedback because nobody had any troubles while the existing ones are solved too you can rename internal functions, move code, use different libraries all day long, but if it comes to command lines and user interfaces (CLI params are a user interface) you need always to be very careful 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: [Bug 1106637] New: odb: FTBFS in rawhide
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 23:48:10 -0500 Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 11 Jun 2014 20:01:19 -0700 Dave Johansen davejohan...@gmail.com wrote: On Wed, Jun 11, 2014 at 7:49 PM, Dave Johansen davejohan...@gmail.com wrote: I resolved the issue with ODB not building with gcc 4.9, but it appears that there's something going wrong with the ARM build. I don't have access to a Fedora 21 machine or ARM hardware to debug this issue, so does anyone have any ideas on what I can do to get the ARM build working on Fedora 21? Thanks, Dave Sorry for the multiple emails but I forgot to include the link to the failed build: Task: http://koji.fedoraproject.org/koji/taskinfo?taskID=7038059 Failed ARM Build: https://kojipkgs.fedoraproject.org//work/tasks/8064/7038064/build.log Thanks, Dave /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/4.9.0/plugin/include/config/arm/arm.h has in it #include config/vxworks-dummy.h which i think either needs to be wrapped in an ifdef or the file needs to be provided. either way it is a gcc bug. gcc has been fixed, and i resubmitted your build, odb is now built Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTmzIeAAoJEH7ltONmPFDR2h0P/1gWebpz7z/qSGqilDiDK4TT kBZIddnOg9I1eTRuBUQcn9M/4WDd2PJq3MRjzoncUcbtWMc4eiRKbBjUmmRfHMXP xkmsi3Lo5fvZ6xAYf6QHi/AJvh/jlP1URpEFZ3X4n5P16FUYm14gHLBkjrxO0Uek yZcnMCijuAees8s9RAJpbgD/PsomEdQU3Y/uJUDGX+t+tntRmkA4icqX0qkChbjm EttULlp50ta7D/eTrw648lMpzGS7T7bfX1shXHu9kmCSeJ8Qpa1kv7N5jUaHub4I KPPq56GjwCzbuxJMzfcZTYkGMKxq1f411PjjUp6dOiRnO++9X1B72PjpG+XB5iEX myNtd+rzZklRn15Ji5Kj2EA6ORnL5Bq/vM8aHL8+b7tot/khLHwpyAb5Mfh6VLMi JjUgzAx4NTFh9E+OkWgiPe0E6MHj/qLqaQpxiUCS//1GCTslXRlK6dqgUyVS/kEt MRO7GF0IZ4jRzEeef578qE0VF5ia+Ku0bIrXuiiMota9YY8Wj2hZACrF1MFiwYLb DqVjEA5qmb6FwuxP4P07dIGajtIzKhJ65iKDSO2NgTCSPgYUZeBaAowv9z3d3m35 YHoTE2wgdSVmo0QRdZxnKKlhOYHjlEXrXmSfSksTCaJrh7Eku0J0vwOaivIwMq19 j9SJRDi75atlf+iF4WdS =mOvz -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
Intent to retire postler
Hi, I intend to retire postler. It FTBFS in the last mass rebuild and upstream recommends to switch to geary instead. Thomas -- 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
If you have any other suggestions other than keeping the name, we will be open to consider them. My suggestion is to keep the name, but as you're not open to that option, there's no point in me bothering, is there? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] Proposal to CANCEL: 2014-06-16 Fedora QA Meeting
Hi folks! I don't think we have anything that needs to be discussed in a meeting tomorrow, so I'm proposing to cancel it. Everyone seems to have things to be pushing along with - please, folks who are working on Taskotron and Fedora.next WG co-operation move along with that, and keep pushing on Fedora 19 and Fedora 20 updates testing and Fedora Rawhide pre-Alpha validation testing! If anyone has anything that does need to be talked over, please do reply to this mail (or send out a meeting announcement mail) and we'll go ahead and run the meeting. Thanks folks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- 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
Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it. -- Michael Scherer -- 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 14.06.2014 02:59, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it what are you talking about? *nobody* asked that *nobody* the point is *not* break YUM as name and in documentations as well as thousands of howtos, articles and books you can't re-write and gain the missing pieces of compatibility 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
Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit : On 13.6.2014 14:58, Reindl Harald wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do. Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ? It happened in the past, and I do not remember seeing so much complains.. -- Michael Scherer -- 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
Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit : Am 14.06.2014 02:59, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it what are you talking about? *nobody* asked that *nobody* Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed. If you tell me nothing should be removed forever, then you ask to keep yum forever. If not, then tell what can be removed and when, and others do the same. the point is *not* break YUM as name and in documentations as well as thousands of howtos, articles and books you can't re-write and gain the missing pieces of compatibility So ok, let the yum name being used by yum code, cause you want to keep how to running ( ie, that mean understand all options and everything like command line ), and that's it. DNS is DNF, and yum is what you have now, since any option change would result into broken howtos. Again, tell what can be removed and/or changed. -- Michael Scherer -- 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 14.06.2014 03:04, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit : On 13.6.2014 14:58, Reindl Harald wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do. Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ? It happened in the past, and I do not remember seeing so much complains.. maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage as said repeatly in that thread: go ahead and propose to rename GNOME3 because it is no longer GNOME go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0 and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it 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
Am 14.06.2014 03:10, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit : Am 14.06.2014 02:59, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it what are you talking about? *nobody* asked that *nobody* Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base? if someone takes the word improve in his mouth i don't see a place for remove in the same context the dirty codebase grown that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution 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
Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit : Am 14.06.2014 03:04, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 15:07 +0200, Petr Spacek a écrit : On 13.6.2014 14:58, Reindl Harald wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him why do so many developers not understand that simple fact? I don't think that simple fact that DNF is re-write of YUM justifies re-naming and re-training all users. Users don't care what you do with the source. And of course, users will complain no matter what you do. Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ? It happened in the past, and I do not remember seeing so much complains.. maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage You may not realize, but having someone who do not do your job telling you how to do it is perceived as pretty annoying for a lot of people. as said repeatly in that thread: go ahead and propose to rename GNOME3 because it is no longer GNOME Gnome is not a single software, it is a brand, and a collection of software. Keeping the brand is likely the reason why it was not renamed. But the part that did change visually, ie the windows manager and the shell among others got renamed from whatever it was named to gnome-shell. Same goes for rhytmbox, afaik. go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0 I fail to see how comparing changes in more than 15 years is relevant to the current discussion. Nor even how anecdotal point of data is relevant. and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ). So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way ? Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? -- Michael Scherer -- 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 14.06.2014 03:24, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit : Like they complained when up2date was replaced by yum ? when zipper replaced whatever they used to have on *suse before ? When pkgin replaced pkg_add on some of the BSD ? It happened in the past, and I do not remember seeing so much complains.. maybe people just have enough of repeated iterations every few months breaking compatibility left and right while it would have been possible to replace/improve things without breakage You may not realize, but having someone who do not do your job telling you how to do it is perceived as pretty annoying for a lot of people. you may not realize but having someone deciding changes and what you have to adopt on your setups is pretty annoying for a lot of people called users as said repeatly in that thread: go ahead and propose to rename GNOME3 because it is no longer GNOME Gnome is not a single software, it is a brand, and a collection of software. Keeping the brand is likely the reason why it was not renamed. But the part that did change visually, ie the windows manager and the shell among others got renamed from whatever it was named to gnome-shell. Same goes for rhytmbox, afaik. that does not change the fact from the users point of view it is no longer GNOME go ahead and propose to rename Linux because 3.15 is no longer Linux 1.0 I fail to see how comparing changes in more than 15 years is relevant to the current discussion. Nor even how anecdotal point of data is relevant. i fail to see the need of rename the well known package manager and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ). because both where a complete different product and not just a new version, DNF is just a new version of YUM and that's what major version numbers are for So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way? yes Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations 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
Le samedi 14 juin 2014 à 03:20 +0200, Reindl Harald a écrit : Am 14.06.2014 03:10, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:03 +0200, Reindl Harald a écrit : Am 14.06.2014 02:59, schrieb Michael Scherer: Le vendredi 13 juin 2014 à 10:39 -0400, Steve Clark a écrit : On 06/13/2014 09:03 AM, drago01 wrote: On Fri, Jun 13, 2014 at 2:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 13.06.2014 14:53, schrieb Jan Zelený: That being said, the reason for not renaming dnf to yum is that renaming this project to yum will do nothing else than to confuse its users, as they will think this is still yum and they should expect from dnf it what they expected from yum. They should not. And dnf is not yum, I'm really sorry if you think it is. the user expects that anyways if you replace something he did not asked for replace it and what just worked for him Well there are different levels of works i.e just because something works that something does not have to be the best possible implementation of something ... Horses worked too but at some point we decided that cars work better and moved on. Yes but who is this better for? A few developers or the mass of people and documentation that are used to using yum. With cars it was obviously better for me - dnf not so obvious. So far in this thread, I see no one stepping to maintain yum in the long term, just people asking to others to do it. But having someone volunteering to maintain it would be the solution. People who want to keep yum forever, just maintain it what are you talking about? *nobody* asked that *nobody* Nobody did ask that explicitly. But if people want to keep all howto running, either we keep yum as is, or we define what exactly should be preserved and what can be removed why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base? likely yes. Also because the more code you have, the more corner case you can face, the more time you spend on testing, reimplementing, etc, etc. the dnf developers did a very good job engaging the users to know what matter to them, to integrate likely better or more flexible solution, etc. Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well. And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform. The less code you have to port, the less time it take (same goes for testing, documenting, translating) if someone takes the word improve in his mouth i don't see a place for remove in the same context the dirty codebase grown that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well. a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts ? throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ? (remember, you said that no one want to have everything forever, so let's be precise on what you want) And you can hardly complain to not be listened if you do not answer to precise questions when someone is willing to listen and try to find a solution. -- Michael Scherer -- 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
Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit : Am 14.06.2014 03:24, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:10 +0200, Reindl Harald a écrit : and that changes where much bigger than a fork of YUM renamed for no good reason especially in context of replace it it was renamed to provides side by side installation among others. I am sure that people would have been more upset if it was not done this way. ( as seen by the migration to gnome 3/kde 4 and people complaining exactly on that ). because both where a complete different product and not just a new version, DNF is just a new version of YUM and that's what major version numbers are for So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way? yes so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ? Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken. Yet, do you advocate bringing back the old API that no one liked, and more importantly, you volunteer to do that ? -- Michael Scherer -- 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 14.06.2014 03:36, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:20 +0200, Reindl Harald a écrit : why do functions and options need to be removed due a code-rewrite/re-factoring? to clean up the code base? likely yes. Also because the more code you have, the more corner case you can face, the more time you spend on testing, reimplementing, etc, etc. the dnf developers did a very good job engaging the users to know what matter to them, to integrate likely better or more flexible solution, etc. maybe in the meantime i remember bugreports for keepcache at the begin of this year which where closed with WONTFIX as well as no we don't protect the OS by allow 'dnf remove kernel dnf' while yum -y remove kernel don#t touch the running one Everybody I know who looked at the yum python api told me it was a bit horrible. So a cleanup was needed for that. There was demand from packagekit developers to have a cleaner API as well, and I would hope that tools like puppet/ansible would benefit as well. And since that's python, you also have the need to be python 3 compatible, which is a rather big task, as seen by the slow migration of the rest of the platform. The less code you have to port, the less time it take (same goes for testing, documenting, translating) the internal API is between developers the options and CLI params are for users different worlds if someone takes the word improve in his mouth i don't see a place for remove in the same context the dirty codebase grown that way because previously unplanned features where included and it it pretty silly to cleanup things by step back from where it came which leads a few years later to the same problems: options left and right are included in a codebase originally not designed for it that's fine for developers because that way you can start every few years from scratch with remove, re-write and cleanup but it hardly gains anything for the users In fact, since developers can fix bug more easily with a code that is clean, it benefits to users as well. you ignore the bugs of missing functions which will be the first so you postponed the work only clean != stripped functionality a smart re-write is using the benefit knowing what all sort of options, functions and configurations where added all the time before and organize the codebase to implement it in a better, more generic way with sane (API) interfaces Perfect, so are you leading the way, or do you continue to tell to people how to make a smart rewrite without being more specific and without putting any efforts? my effort is try to prevent thousands of bugreports did you realize that in this thread it was even suggested to completly remove the yum command over the long even if it is only a symlink? that is not what that page below previously said, that statet very clear that DNF is a temporary name of the next YUM major version what finally means for any user reading this page it will later called YUM, the technology behind the scenes will be more mordern and that's it from the users perspective http://fedoraproject.org/wiki/Features/DNF Preview the next-generation Yum package manager, using hawkey/libsolv for backend Note about the name DNF: it has no relevant meaning, meant as a project name only. Since DNF is a tech preview in Fedora 18 the Python module names can not be 'yum.*' as that would clash with yum itself throwing all away, start with a minimum and be proud it's faster and cleaner is only a short term solution You still didn't answer to the question I asked. How long do you want compatibility be kept, and what compatibility exactly ? yum-plugin-protectbase yum-plugin-tsflags yum-utils Loaded plugins: etckeeper, protectbase, tsflags Usage: yum [options] COMMAND List of Commands: autoremove Remove leaf packages check Check for problems in the rpmdb check-update Check for available package updates clean Remove cached data deplistList a package's dependencies distribution-synchronization Synchronize installed packages to the latest available versions downgrade downgrade a package erase Remove a package or packages from your system fs Acts on the filesystem data of the host, mainly for removing docs/lanuages for minimal hosts. fssnapshot Creates filesystem snapshots, or lists/deletes current snapshots. groups Display, or use, the groups information help Display a helpful usage message historyDisplay, or use, the transaction history info Display details about a package or group of packages installInstall a package or packages on your system list List a package or groups of packages load-transaction load a saved transaction from filename makecache Generate the metadata cache provides Find what package provides the given value reinstall reinstall a package repo-pkgs Treat a repo. as a
Re: F22 System Wide Change: Replace Yum With DNF
Am 14.06.2014 03:42, schrieb Michael Scherer: Le samedi 14 juin 2014 à 03:33 +0200, Reindl Harald a écrit : So maybe you should propose to have dnf named yum 4.0, and then since that's a major version, we would be ok to change the behavior, command lines switch, configuration and backend in a backward incompatible way? yes so, just to be clear, that's ok to change the behavior, command lines switch, configuratio and backend in backward _incompatible_ for yum 4.0 aka dnf, for you ? it is *NEVER* ok to break user interfaces without a damned good reason there is no single reason to break command line switches at all Or even with the name yum and a clear indication, that's something that shouldn't be changed, in which case, yum 3 behavior should be kept, which mean keeping all the code and behavior until later ? jesus christ the code behind has *nothing* to do with the userinterface and options - i have rewritten code of software i maintain for a decade now multiple times and in the meantime there is for sure not a single line the same as started 2003 without break user expectations In the case of dnf, the plugin api did changed. And I doubt people want to bring back the old one. So the user expectation around specific plugin is already broken. no - only if you want it that way as developer you could also say OK, that's the currently used feature set and as we build the whole thing modular we can even ship that modules in the default install Yet, do you advocate bringing back the old API that no one liked, and more importantly, you volunteer to do that ? no i advocate if someone starts to replace things he intergates the plugins instead demand others to do so - if i break API's i adopt code which is using it 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
Am 13.06.2014 16:49, schrieb drago01: Well I replied to his general statements about developers not understanding simple facts ... that aside ... it fits pretty well the horse (yum) is slower so takes longer to get the job done as the car (dnf) ;) well, i tested DNF recently on my Rawhide VM which is happy with 192 MB RAM and zram doing a yum reinstall \* and a simple dnf upgrade don't survive oom-killer because it takes up to 250 MB RAM as far as i have seen in htop http://fedoraproject.org/wiki/Features/DNF talks about better performance and memory footprint - i see :-) dnf remove kernel still offered to uninstall all 3 kernels inlcuding the running one without a warning what would break the complete setup no - you can't educate users maintaining more than 20 machines over many years and just use yum remove kernel to get rid of old ones without look what possible testing versions are installed and list them specific in the command line for now the horse may be slower but it get's done the work better and provides bash-completion for as example --enablerepo while the bash-completion makes it finally faster, the rest is done by the horse while the cowboy is drinking coffee :-) 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
[ACTION REQUIRED] Retiring packages for Fedora 21 v2
The following packages are orphaned or did not build for two releases and will be retired when Fedora (F21) is branched, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life According to https://fedoraproject.org/wiki/Schedule branching will occur not earlier than 2014-07-08. The packages will be retired shortly before. Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Package(co)maintainers === NearTree tmatsuu SteGUI orphan, pingou ale orphan, silfreed alliance chitlesh, tnorth barryorphan, gnat, vicodan bio2jack dtimms bitbake ixs blktap ke4qqq cbmc orphan, shakthimaan cgnslib orphan, chitlesh cleanfeedorphan clutter-gtkmmorphan, rhl cx18-firmwareorphan, athimm dee-qt orphan, jreznik drgeoorphan drgeo-docorphan drwright caillon eclipse-cmakeed orphan, swagiaal emacs-common-museorphan emacs-identica-mode orphan, shakthimaan eqntott orphan, chitlesh espresso-ab orphan, chitlesh fatrat orphan fatrat-subtitlesearchorphan fprint_demo orphan, pingou freetalk orphan, rishi freetalk orphan, rishi fuse-smb szpak g-wrap laxathom gdome2 orphan, sundaram gdome2 orphan, sundaram ghc-chalmers-lava2000orphan, chitlesh ghemical orphan, tolland gnomeradio orphan, itamarjp, roma guile-liblaxathom ha-jdbc orphan hdrprep orphan, silfreed inn orphan, npajkovs, ovasik, s4504kr jbosscache-core orphan, arg jbosscache-support orphan, arg jbrout orphan jcharts orphan jdbm orphan jgroups212 orphan, arg kannel thias, cicku, linuxthomass kguitar davidcornette libghemical orphan liboglappth orphan libopensync-plugin-opie awjb minbar izhar, hicham mopac7 orphan mozilla-firetray hicham mpqc orphan mule orphan nagios-plugins-check_sip orphan nesc
[Bug 1106197] perl-SDL: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1106197 --- Comment #6 from Hans de Goede hdego...@redhat.com --- Hi Yaakov, Matthias (the SDL_gfx owner) lately does not have much time to take care of his Fedora packages, so allow me to jump in here. It seems that upstream has a new SDL_gfx release with rewritten mmx support (which now also supports x86_64), so before we use the bigger hammer and disable mmx altogether lets first try that. I've just started a rawhide build of the new SDL_gfx and as soon as that is finished I'll start rebuilding deps including SDL_gfx. Hopefully that will resolve this FTBFS bug. Regards, Hans -- 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=VarUZrILKpa=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 --- Comment #7 from Hans de Goede hdego...@redhat.com --- Hmm, this seems to build fine on x86_64 and i686 now, but the test suite hangs on ARM. Once the ARM build has timed out, I'll go and disable the test which causes it to hang on ARM for now. -- 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=GU7nHCnaLHa=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 Hans de Goede hdego...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2014-06-13 07:29:16 --- Comment #8 from Hans de Goede hdego...@redhat.com --- With the one test for the obscure sdlx_controller_interface disabled, it builds fine on ARM too. I've send a mail to the arm list in case one of the arm guys wants to take a look. -- 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=x9ln9t8UXCa=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 1099373] perl-SDL-2.540-5.fc21 FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1099373 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-SDL-2.544-3.fc21 Resolution|--- |RAWHIDE Last Closed||2014-06-13 07:54:02 --- Comment #3 from Petr Pisar ppi...@redhat.com --- (In reply to Petr Pisar from comment #2) This happens only on i686 probably. Addressed in bug #1106197. -- 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=zwfi1jzZTxa=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
