Re: unable to run abrt
On 03/04/2013 06:14 AM, Dan Mashal wrote: On Sun, Mar 3, 2013 at 4:10 PM, Christopher Meng cicku...@gmail.com wrote: 在 2013-3-4 AM7:30，Dan Mashal dan.mas...@gmail.com写道： I understand but is this happening on 18? I know it's happening on rawhide for sure. Yes. F17 F18 Rawhide. I'll recheck today later. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Looks like some update fixed it. Works for me now. Dan Hi, seems like the abrt server was down and unfortunately the error message is really bad in such cases. --Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: unable to run abrt
Me, too. Thanks. BTW,uReport still have some problems. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Test-Announce] 2013-03-04 @ 16:00 UTC - Fedora QA Meeting
# Fedora Quality Assurance Meeting # Date: 2013-03-04 # Time: 16:00 UTC (https://fedoraproject.org/wiki/Infrastructure/UTCHowto) # Location: #fedora-meeting on irc.freenode.net Greetings testers! It's meeting time again very soon. Crap on a stick, so soon. Note to self: Angry Birds is not a good choice of app with which to 'test your tablet'. Especially not the night before a meeting. For three hours solid. This is a reminder of the upcoming QA meeting. Please add any topic suggestions to the meeting wiki page: https://fedoraproject.org/wiki/QA/Meetings/20130304 The current proposed agenda is included below. It's short, but I'm not cancelling the meeting, as we have several follow-up topics and likely a discussion on what to do with trac. == Proposed Agenda Topics == 1. Previous meeting follow-up 2. Open floor -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora 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
Review swaps!
Hello All! I've got few review requests which got stuck for a while, and I'd love to trading reviews with anyone. * https://bugzilla.redhat.com/906473 - erlang-ranch - Socket acceptor pool for TCP protocols * https://bugzilla.redhat.com/906481 - erlang-cowboy - Small, fast, modular HTTP server written in Erlang * https://bugzilla.redhat.com/906482 - erlang-mimetypes - Erlang MIME types library * https://bugzilla.redhat.com/906486 - erlang-parsexml - Simple DOM XML parser with convenient and very simple API Please help me to add them to Fedora, and I'll help you in return! -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F16 and F18: bugzilla, bugs and EOL
Hi! There an interesting thing happened in gugzilla recently. Some bug (https://bugzilla.redhat.com/show_bug.cgi?id=809773) is applied for F16. There are some (five, ten, twenty,...) simmilar bugs which are, ofcouse, are marked as dublicate. But. Last one is for F18 (https://bugzilla.redhat.com/show_bug.cgi?id=895465), and it is marked as dublicate of F16 bug when, you know, F16 is automatcaly EOF. So the first bug is automaticaly closed as well a new one. Nothing strange here? We have new bug reports that are closed automaticaly wiht no solution. Something should be changed here, how do you think? Dmitrij S. Kryzhevich. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 and F18: bugzilla, bugs and EOL
- Original Message - Hi! There an interesting thing happened in gugzilla recently. Some bug (https://bugzilla.redhat.com/show_bug.cgi?id=809773) is applied for F16. There are some (five, ten, twenty,...) simmilar bugs which are, ofcouse, are marked as dublicate. But. Last one is for F18 (https://bugzilla.redhat.com/show_bug.cgi?id=895465), and it is marked as dublicate of F16 bug when, you know, F16 is automatcaly EOF. So the first bug is automaticaly closed as well a new one. Then the original one could be reopened and version set to F18. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. It would be probably possible to check all dupes automatically but again a corner case, fixable manually (if somebody takes care). Btw. as asked frequently in the previous EOL thread and to make it easier for me and upcoming guys responsible for EOL - the script is now available in the GIT of Fedora Project Schedule hosted project [1]. Jaroslav [1] https://fedorahosted.org/fedora-project-schedule/ Nothing strange here? We have new bug reports that are closed automaticaly wiht no solution. Something should be changed here, how do you think? Dmitrij S. Kryzhevich. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
On 02/28/2013 12:58 PM, Matthias Runge wrote: Dear list, Django 1.5 was released about two days ago. I'd like to push a build to rawhide, but I assume, that will break many dependent packages. The plan is, to delay the push, until other packages are fixed, or to push in about 14 days. I have a scratch-build build ready, one might to try, it should install cleanly e.g. on Fedora 18. http://kojipkgs.fedoraproject.org//work/tasks/3880/5063880/python-django-1.5-1.fc19.noarch.rpm To get this more coordinated, I started a wiki page[1], including all django packages. As far as I knew, if that package is django-1.5 ready, I also made a remark. I still don't like the idea to rename the current python-django package to python-django14 and to make a new package python-django15. The latter may not provide python-django or Django for compatibility reasons. I'd stick with https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name and still try to get python-django14 as new package accepted[2]. I can offer support in changing requirements from python-django/Django to python-django14. Matthias [1] https://fedoraproject.org/wiki/User:Mrunge/django15 [2] https://bugzilla.redhat.com/show_bug.cgi?id=916676 -- Matthias Runge mru...@matthias-runge.de mru...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
another abrt problem
Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another abrt problem
On 03/04/2013 01:17 PM, Neal Becker wrote: Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. Hi, I'm pretty sure there is a way to achieve this with the current abrt design, can you please describe how do you imagine this should work? Thank you, Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another abrt problem
Jiri Moskovcak wrote: On 03/04/2013 01:17 PM, Neal Becker wrote: Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. Hi, I'm pretty sure there is a way to achieve this with the current abrt design, can you please describe how do you imagine this should work? Thank you, Jirka One possibility would be to simply add an dialog to abrt-gui to save the core dump to some user-specified location. It could offer to run gdb, but that's not necessary. I suppose it would also be good to have a non-gui option as well, but I don't know what that would be. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another abrt problem
On 03/04/2013 01:28 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 03/04/2013 01:17 PM, Neal Becker wrote: Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. Hi, I'm pretty sure there is a way to achieve this with the current abrt design, can you please describe how do you imagine this should work? Thank you, Jirka One possibility would be to simply add an dialog to abrt-gui to save the core dump to some user-specified location. It could offer to run gdb, but that's not necessary. I suppose it would also be good to have a non-gui option as well, but I don't know what that would be. You have two options: 1) in /etc/abrt/abrt-action-save-package-data.conf you can change the option ProcessUnpackaged = no to yes 2) you can just set ulimit -c unlimited and abrt will create the core in the CWD in format core.PID as it is by default without abrt and then you can pass it to gdb Regards, Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another abrt problem
Jiri Moskovcak wrote: On 03/04/2013 01:28 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 03/04/2013 01:17 PM, Neal Becker wrote: Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. Hi, I'm pretty sure there is a way to achieve this with the current abrt design, can you please describe how do you imagine this should work? Thank you, Jirka One possibility would be to simply add an dialog to abrt-gui to save the core dump to some user-specified location. It could offer to run gdb, but that's not necessary. I suppose it would also be good to have a non-gui option as well, but I don't know what that would be. You have two options: 1) in /etc/abrt/abrt-action-save-package-data.conf you can change the option ProcessUnpackaged = no to yes 2) you can just set ulimit -c unlimited and abrt will create the core in the CWD in format core.PID as it is by default without abrt and then you can pass it to gdb Regards, Jirka If 2), will abrt still operate as normal on fedora package core files? We don't want to permanently disable abrt just to enable normal use of gdb on our own code. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another abrt problem
On 03/04/2013 01:37 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 03/04/2013 01:28 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 03/04/2013 01:17 PM, Neal Becker wrote: Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. Hi, I'm pretty sure there is a way to achieve this with the current abrt design, can you please describe how do you imagine this should work? Thank you, Jirka One possibility would be to simply add an dialog to abrt-gui to save the core dump to some user-specified location. It could offer to run gdb, but that's not necessary. I suppose it would also be good to have a non-gui option as well, but I don't know what that would be. You have two options: 1) in /etc/abrt/abrt-action-save-package-data.conf you can change the option ProcessUnpackaged = no to yes 2) you can just set ulimit -c unlimited and abrt will create the core in the CWD in format core.PID as it is by default without abrt and then you can pass it to gdb Regards, Jirka If 2), will abrt still operate as normal on fedora package core files? We don't want to permanently disable abrt just to enable normal use of gdb on our own code. - yes, the only problem is, that it will create 2 cores (one in /var/ one in CWD) for every crash --Jirka -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: another abrt problem
Jiri Moskovcak wrote: On 03/04/2013 01:37 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 03/04/2013 01:28 PM, Neal Becker wrote: Jiri Moskovcak wrote: On 03/04/2013 01:17 PM, Neal Becker wrote: Is it possible to use abrt as intended and still be able to get core dumps from non-fedora binaries (e.g., my own code)? Right now, all core dumps are redirected to abrt. We need a way to be able to use gdb to debug core dumps. I know we can turn off abrt entirely /proc/sys/kernel/core_pattern but that's not acceptable! We need a way that allows abrt to be used for fedora packages, while at the same time allowing capturing core dumps to run gdb on for non-fedora packages. If there is a way in the current abrt design, it is not sufficiently obvious/discoverable. Hi, I'm pretty sure there is a way to achieve this with the current abrt design, can you please describe how do you imagine this should work? Thank you, Jirka One possibility would be to simply add an dialog to abrt-gui to save the core dump to some user-specified location. It could offer to run gdb, but that's not necessary. I suppose it would also be good to have a non-gui option as well, but I don't know what that would be. You have two options: 1) in /etc/abrt/abrt-action-save-package-data.conf you can change the option ProcessUnpackaged = no to yes 2) you can just set ulimit -c unlimited and abrt will create the core in the CWD in format core.PID as it is by default without abrt and then you can pass it to gdb Regards, Jirka If 2), will abrt still operate as normal on fedora package core files? We don't want to permanently disable abrt just to enable normal use of gdb on our own code. - yes, the only problem is, that it will create 2 cores (one in /var/ one in CWD) for every crash --Jirka And what will 1) do? man page says: ProcessUnpackaged = yes | no When set to yes, abrt will catch all crashes in the system. When set to no, it will catch crashes only in executables which belong to an installed package. The default is no. Ok, if set to yes it will 'catch crashes'. But what will it do with them? I seriously doubt I'm the only developer who's going to find this confusing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Testing valgrind in rawhide (separate valgrind-debuginfo package)
Hi, I am looking for some valgrind users that want to try out the latest valgrind package in rawhide. If you use valgrind please try out the new valgrind-3.8.1-10.fc19 version in rawhide. It is the first version that puts the debuginfo in a separate valgrind-debuginfo package (this saves ~35MB from the main packages). http://koji.fedoraproject.org/koji/buildinfo?buildID=399059 Upstream used to recommend against stripping debuginfo from the valgrind vg preload libraries because it produced less usable warning/error messages. But since a long time now valgrind intercepts are done in a different way and just having the dynsym symbols around should be enough. Please let me know (or file a bug report) if using the new valgrind package from rawhide gives less useful warnings/errors (and whether installing valgrind-debuginfo solves any of such issues). Thanks, Mark BTW. I also backported some issues that showed up with the new kernel and glibc to the f18 valgrind package, but obviously not the debuginfo separation. Testers for valgrind-3.8.1-9.fc18 currently in updates-testing also welcome. But this update should just contains benign bugfixes since it is targetted for stable. https://admin.fedoraproject.org/updates/FEDORA-2013-3322/valgrind-3.8.1-9.fc18 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dietlibc
On Fri, Mar 1, 2013 at 4:21 PM, Bill Nottingham nott...@redhat.com wrote: Toshio Kuratomi (a.bad...@gmail.com) said: I recalled this set of issues too from my previous time in fesco but I didn't find the meeting logs with the information. I did find this meeting log: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531 where fesco voted to disallow static linking to dietlibc but deferred the question of linking to dietlibc at all. On that question, I would tend to agree with patrice's email that we've moved towards certain core systems being too core to let people use an alternative in Fedora (although alternatives may be provided). Examples are kernel (no kmods) and C compiler (IIRC, there was discussion about building with clang that resolved in at least a decision on the list to use gcc). There is a line somewhere as to what is core enough to warrant this treatment but I think it's reasonable to think that the libc implementation falls on the same side as the C compiler. I'd agree here - note that these 4 were also packages maintained by the former maintainer of dietlibc... it would reasonably be simple just for the new maintainer to fix that as part of picking them up. I've already tried it with kismet, ip-sentinel and dhcp-forwarder, with no observable issues. util-vserver is still orphaned. Paul, if you'd like me to handle dhcp-forwarder for you, let me know. -J Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dietlibc
On Sat, Mar 2, 2013 at 9:21 PM, Kevin Kofler kevin.kof...@chello.at wrote: Jon Ciesla wrote: I see no reason not to keep dietlibc around for development use, but I'd rather see packages use glibc. We agree then. But if we want to keep dietlibc, it needs to be fixed to comply with the packaging guidelines and best practices, i.e.: * Shared library build needs to be enabled. I see no reason to build this library as static only as Enrico is doing. We tolerate this where upstream does not support shared builds at all, but this is not the case here. * The main package should contain the shared library (and the documentation that's relevant at runtime, in particular COPYING) only. Right now it contains some stuff which probably belongs into -devel. * The main package must not require -devel as it does now. * The -devel package should not contain the static library, which should instead be in a -static subpackage. * The -lib package (which is currently not built by default, it contains the shared library if you enable shared build) should simply be the main package. It doesn't make sense to have a -lib subpackage of a library. * The -header subpackage should really be called -headers (There's more than one header! And it'd also be consistent with glibc.) or folded into -devel (though then it can't be noarch anymore). Excellent, can you file all of this as a BZ against dietlibc so we can track it, and not rely on my imperfect memory? I don't want to miss a thing*. -J *No singing! Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20130304 changes
Compose started at Mon Mar 4 08:15:12 UTC 2013 Broken deps for x86_64 -- [HippoDraw] HippoDraw-python-1.21.3-6.fc19.x86_64 requires libboost_python.so.1.50.0()(64bit) [condor] condor-plumage-7.9.1-0.1.fc19.4.x86_64 requires libboost_system.so.1.50.0()(64bit) [couchdb] couchdb-1.2.1-2.fc19.x86_64 requires libicuuc.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicui18n.so.49()(64bit) couchdb-1.2.1-2.fc19.x86_64 requires libicudata.so.49()(64bit) [dragonegg] dragonegg-3.1-19.fc19.x86_64 requires gcc = 0:4.7.2-9.fc19 [epiphany-extensions] epiphany-extensions-3.6.0-1.fc19.x86_64 requires epiphany(abi) = 0:3.6 [eucalyptus] eucalyptus-nc-3.2.1-3.fc19.x86_64 requires euca2ools = 0:2.1.3 [fawkes] fawkes-guis-0.5.0-5.fc19.i686 requires libgraph.so.5 fawkes-guis-0.5.0-5.fc19.x86_64 requires libgraph.so.5()(64bit) fawkes-plugin-clips-0.5.0-5.fc19.i686 requires libclipsmm.so.2 fawkes-plugin-clips-0.5.0-5.fc19.x86_64 requires libclipsmm.so.2()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libgeos-3.3.6.so()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) fawkes-plugin-player-0.5.0-5.fc19.x86_64 requires libboost_signals-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_thread-mt.so.1.50.0()(64bit) fawkes-plugin-tabletop-objects-0.5.0-5.fc19.x86_64 requires libboost_system-mt.so.1.50.0()(64bit) [fcitx-keyboard] fcitx-keyboard-0.1.3-1.fc18.x86_64 requires libicuuc.so.49()(64bit) [fcitx-libpinyin] fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2(LIBPINYIN)(64bit) fcitx-libpinyin-0.2.1-2.fc19.x86_64 requires libpinyin.so.2()(64bit) [flowcanvas] flowcanvas-0.7.1-8.fc18.i686 requires libgraph.so.5 flowcanvas-0.7.1-8.fc18.x86_64 requires libgraph.so.5()(64bit) [freeipa] freeipa-server-strict-3.1.2-3.fc19.x86_64 requires krb5-server = 0:1.11 [gcc-python-plugin] gcc-python2-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python2-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-debug-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 gcc-python3-plugin-0.11-1.fc19.x86_64 requires gcc = 0:4.7.2-8.fc19 [gdcm] gdcm-2.0.18-6.fc18.i686 requires libpoppler.so.26 gdcm-2.0.18-6.fc18.x86_64 requires libpoppler.so.26()(64bit) [gedit-valencia] gedit-valencia-0.3.0-11.20120430gite8a0f500555be.fc18.x86_64 requires libvala-0.18.so.0()(64bit) [gnome-applets] 1:gnome-applets-3.5.92-3.fc18.x86_64 requires libgweather-3.so.1()(64bit) [gnome-panel] gnome-panel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) gnome-panel-devel-3.6.2-6.fc19.i686 requires libgnome-desktop-3.so.5 gnome-panel-devel-3.6.2-6.fc19.x86_64 requires libgnome-desktop-3.so.5()(64bit) [kdevelop-python] kdevelop-python-1.4.1-2.fc19.i686 requires libpython2.7-kdevelop.so.1.0 kdevelop-python-1.4.1-2.fc19.x86_64 requires libpython2.7-kdevelop.so.1.0()(64bit) [libgda] 1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit) [matreshka] matreshka-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-mofext-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-mofext-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-ocl-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-ocl-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-uml-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-uml-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-amf-utp-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-amf-utp-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-fastcgi-0.3.0-3.fc19.i686 requires libgnarl-4.7.so matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-fastcgi-0.3.0-3.fc19.x86_64 requires libgnarl-4.7.so()(64bit) matreshka-sql-core-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-core-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-postgresql-0.3.0-3.fc19.i686 requires libgnat-4.7.so matreshka-sql-postgresql-0.3.0-3.fc19.x86_64 requires libgnat-4.7.so()(64bit) matreshka-sql-sqlite-0.3.0-3.fc19.i686 requires
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Thu, Feb 28, 2013 at 09:20:51AM -0600, John Reiser wrote: On 02/28/2013 06:55 AM, Kay Sievers wrote: On Mon, Feb 25, 2013 at 6:02 PM, Andy Gospodarek agosp...@redhat.com wrote: I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. This only matters if there are multiple devices created by a driver for one and the same pci device. Like when we have only one entry in lspci, but multiple interfaces of the same type having this one device as a parent. Is this really common? I would expect this is a very rare exception. How does this relate to a hosting service which assigns a different IP4 for each client domain to the same physical ethernet port? My service has many dozen different IP4 [advertised via DNS] assigned to the same port. No conceptual change here. You would still assign many IPv4 addressess to the same network device, just as you always have. The only difference is instead of assigning them to device eth0, you would assign them to device en1. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 and F18: bugzilla, bugs and EOL
Jaroslav, On Mon, 2013-03-04 at 06:38 -0500, Jaroslav Reznik wrote: Btw. as asked frequently in the previous EOL thread and to make it easier for me and upcoming guys responsible for EOL - the script is now available in the GIT of Fedora Project Schedule hosted project [1]. thanks for putting this up! This will make it easier to understand what EOL script is doing and suggest improvements. Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. Thanks, Matt -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 and F18: bugzilla, bugs and EOL
- Original Message - Jaroslav, On Mon, 2013-03-04 at 06:38 -0500, Jaroslav Reznik wrote: Btw. as asked frequently in the previous EOL thread and to make it easier for me and upcoming guys responsible for EOL - the script is now available in the GIT of Fedora Project Schedule hosted project [1]. thanks for putting this up! This will make it easier to understand what EOL script is doing and suggest improvements. You're welcome! The script itself is pretty dumb, just closes the bugs served by the CSV file. For the queries, see for example [1]. To improve the process, I have an idea of running the script for more passes. First to close the bugs with clear resolution - in the new, assigned, on devel statuses. As these are pretty clear nobody touched them, or just assigned. And then the second round for more corner case ones - as in the modified state etc. And based on the amount of the bugs (I can't check 1000 bugs manually), do the final close down using common sense, not a script. And I'm as always open to any other ideas and now even patches ;-) Jaroslav [1] https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora18 Best regards, Tadej -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
GNOME 3.7.91
If you're planning on doing a 3.7.91 build manually (i.e. that's not picked up by mclazy, or one you'd rather do on your own), can you add them to the spreadsheet please: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc This way we can QA and test the release and push it in one go. I'll also be putting links to build failures on the same sheet. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Django-1.5 build
Le Ven 1 mars 2013 17:41, Miloslav Trmač a écrit : (In the recent years, the number of upstreams and packagers that can't or won't support a smooth upgrade path and want to have several versions of the same package installed has noticeably increased, and we may need to react to this by designing a different parallel installation setup and packaging guidelines - but let's not do it by ignoring the current guidelines one package at a time.) IMHO the compat-foo naming convention is much better, as it clearly states the package is ultimately going to the killing block, so people need to migrate away now, while fooxy implies xy is here for the long run and people needn't worry. -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Non responsive state for systemd
Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 884354] CVE-2012-6329 perl: possible arbitrary code execution via Locale::Maketext
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=884354 --- Comment #13 from Petr Pisar ppi...@redhat.com --- Created attachment 705056 -- https://bugzilla.redhat.com/attachment.cgi?id=705056action=edit Fix ported to perl-5.8.8 -- 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=xrv4v5poTca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: On Mon, Feb 25, 2013 at 11:02:55AM -0600, Andy Gospodarek wrote: On Sat, Feb 23, 2013 at 10:28:21AM +0100, Bill Nottingham wrote: Matt Domsch (matt_dom...@dell.com) said: On Wed, Feb 13, 2013 at 01:57:42PM -0600, Bill Nottingham wrote: If we can solve the installtime naming convention choice to not eliminate biosdevname, be able to disable systemd/udevd naming, and have the default be possible on a per-system-vendor basis, and solve the NPAR/SR-IOV/Mellanox naming problems, then I can support this proposal. Without fixing these shortcomings though, my customers will have a fit at me. If you're agreeing that biosdevname should be limited to type9/type41 (if I'm reading you right), and if the systemd/udev names still use those fields, what parts of biosdevname are you still requiring? The actual namespace used, or something else? I'd prefer if we didn't force users through another namespace change. I took a lot of flack for changing the namespace once. From their perspective, it's still udev doing the renaming, only now the code moved from a udev helper into udev itself. True; the users likely don't care other than how they enable/disable it. I'd like to see the SR-IOV NPAR devices handled. Those aren't represented in type9/type41, and their commonplace on Dell systems. I'd like to see the Dell-specific PCI VPD-R code from biosdevname included in udev, as that's used to map multi-port devices to port numbers. Those aren't represented in type9/type41, and they're commonplace on Dell systems. OK. I'd like to see kernel driver work to be sure every multi-port driver with the same PCI b/d/b/f sets dev_id. That isn't necessarily true today, which makes it hard to trust. biosdevname needs this too, until such a time as it's dead. Do we have a list of these, or is it a matter of doing a driver audit? CC'ing gospo. (Thanks, Bill, though I've been following this thread as I am on the list). Right now almost no drivers actually set dev_id. In fact mlx4_en, cxgb4, and sfc seem to be the only ones right now. If we feel like this a requirement there will be work on the kernel side to add this. The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. Good catch. drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? I believe so, yes. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On Mon, Mar 04, 2013 at 07:56:51AM -0800, David Highley wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did system logs or dmesg contain any hints? When systemd dies, it prints some explanation. You may also check if there are any /core.* files on you filesystem and generate a backtrace. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Something like irq XX: nobody cared (try booting with the irqpoll option? It would point to hardware/driver problem. Again, you may find more information in dmesg. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 10:03:01AM -0600, Andy Gospodarek wrote: On Mon, Mar 04, 2013 at 09:01:35AM -0600, Matt Domsch wrote: On Mon, Mar 04, 2013 at 08:44:55AM -0600, Domsch, Matt wrote: The challenge here is that because struct netdev is initialized to all zeros, code that consumes dev_id can't tell the difference between a driver _setting_ the value to 0 because it has 2 ports 0 and 1, and a default (unset) value of 0. I think the only solution here is to make sure the kernel drivers, if they need to set it, always set this non-zero, so udev, seeing a non-zero value, knows it's a valid value to use. These seem to be the 4 drivers currently setting dev_id: drivers/net/ethernet/chelsio/cxgb4/t4_hw.c: adap-port[i]-dev_id = j; drivers/net/ethernet/freescale/fec.c: fep-dev_id = dev_id++; Look up a few lines: /* setup board info structure */ fep = netdev_priv(ndev); fep is not a pointer to the net_device, but to the private device structure. This is why I didn't include it in the list. Good catch. drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? I believe so, yes. Ok, good. I did like your idea to possibly set this to something other than 0 in the default case and then make sure that any driver that needs to set it can do so. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Amide, looking for a co-maintainer
Hi all, I noticed that Amide is orphaned, even if it is still possible to install in f18. Is anyone interested in helping to maintain it? Thanks, Mario BTW: I tried to take ownership, but I can only do that for 17. Is there something wrong with my FAS account? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Amide, looking for a co-maintainer
On 4 March 2013 17:33, Mario Ceresa mrcer...@gmail.com wrote: Hi all, I noticed that Amide is orphaned, even if it is still possible to install in f18. Is anyone interested in helping to maintain it? Thanks, Mario BTW: I tried to take ownership, but I can only do that for 17. Is there something wrong with my FAS account? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It looks like the package was retired (perhaps mistakenly - there is no dead.package file) for f18 and devel, which is why you cannot take ownership of it for those branches. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
iptables 1.4.10 update, libxtables so version bump
Hello, iptables has been updated in Fedora rawhide. The version of libxtables has been bumped to 10. Therefore all packages, that require libxtables need to be rebuilt for the new lib. iproute has been rebuilt already. There are also testing packages for F-18: https://admin.fedoraproject.org/updates/iproute-3.6.0-7.fc18,iptables-1.4.18-1.fc18 Affected Fedora packages: libguestfs perl-IPTables-libiptc Thanks, Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3.7.91
On Mon, Mar 4, 2013 at 7:18 AM, Richard Hughes hughsi...@gmail.com wrote: If you're planning on doing a 3.7.91 build manually (i.e. that's not picked up by mclazy, or one you'd rather do on your own), can you add them to the spreadsheet please: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc This way we can QA and test the release and push it in one go. I'll also be putting links to build failures on the same sheet. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel gpointing-device-settings fails to build in rawhide. The code in git does not seem to be migrated to gsettings either. https://bugzilla.redhat.com/show_bug.cgi?id=914053 Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fedora-r-devel-list] R package ownership changed
Hi, For the record, I took over the ownership of the following package from Sandro (aka red): R-ROC R-affydata R-fibroEset R-hgu133acdf R-hgu95av2cdf R-statmod R-timeDate R-xtable Pierre ___ r-devel mailing list r-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/r-devel
RFC: Fedora revamp proposal
This is a proposal of changes to the way future Fedora cycles should work and integrate changes. Some of the things we want to achieve: * Make rawhide to be reliably installable and usable by developers by coherently introducing changes. * Define the interfaces that applications can rely on (and by inference, the ones that they can't). * Ensure that functionality implemented in Fedora doesn't unintentionally regress, and provide a clear way to change or replace earlier implementations. To do this, we propose to specify three levels of stability we attempt. These are defined at the level of interfaces (e.g. specific library/command/file), not at the level of packages: 1: Long-term ABI for applications that we don't want to break without significant discussion. For now, this will include the stable kernel and libc ABIs 2: Base design: A set of functionality that was implemented and needs to be kept working in any composed tree, including rawhide; may include specific commands. Behavior that other parts of the distribution depends on. Functionality accepted for this tier by FESCo using the planning process, and some interfaces this functionality relies on. 3: Internal API: we'll do our best not to change it within a release lifetime; basically the existing Fedora compatibility and update rules. e.g. Python/Perl/Ruby X.Y version, most library interfaces, and major aspects of UI. We also propose to build up automated tests to verify the tier 1 and tier 2 functionality, and use those tests on newly-built packages to gate inclusion in rawhide. Finally, the planning process will recognize the existence of these tiers by classifying each proposed change: * Changes to tiers 1 and 2: Strong recommendation that new stable APIs have new tests delivered at approximately the same time, if possible. This benefits change owners by diminishing the risk of accidental breakage of the functionality. Existing tests for the functionality must be updated at the same time as well. Waivers may be requested of FESCo. * Complex changes not affecting tiers 1/2 (e.g., new core library version): Strong recommendation that landing of these be coordinated, via the use of side tags or similar features. * Self-contained changes (mostly announcement-only) (e.g. user-visible changes to applications) The original idea for this proposal was discussed at length during FUDCon Lawrence by the following individuals: Stephen Gallagher Jon Stanley Miloslav Trmač Adam Williamson Bill Nottingham Jaroslav Reznik Jesse Keating Paul Frields Emily Dirsh Justin M. Forbes Peter Jones Toshio Kuratomi Additionally, further discussion took place at the Brno Developer Conference between: Bill Nottingham Marcela Mašláňová Miloslav Trmač Stephen Gallagher Tomáš Mráz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 19. That is currently scheduled to happen on or around March 12. Package HippoDraw (orphan) Package PyPE (orphan) Package Temperature.app (orphan) Package afraid-dyndns (orphan) Package alsamixer-dockapp (orphan) Package aplus-fsf (fails to build) Package aswvdial (orphan) Package auto-nng (orphan) Package bamf (orphan) comaintained by: jspaleta Package blazeblogger (orphan) Package bouncycastle-tsp (orphan) Package bzr-explorer (orphan) Package c2050 (orphan) Package c2070 (orphan) Package canto (orphan) Package certmaster (orphan) comaintained by: alikins Package compton (orphan) Package cputnik (orphan) Package dasher (orphan) Package eclipse-m2m-qvtoml (fails to build) Package eclipse-mercurial (fails to build) comaintained by: overholt Package em8300 (orphan) Package emacs-ecb (orphan) Package emacs-rpm-spec-mode (orphan) Package emacs-slime (orphan) Package email2trac (fails to build) Package fcron (orphan) Package ganymed-ssh2 (orphan) comaintained by: akurtakov Package gkrellm-weather (orphan) Package global (orphan) Package gmyth (orphan) Package gnome-mag (orphan) Package griffith (orphan) Package gtksourceview2-sharp (fails to build) Package guimup (orphan) Package haildb (orphan) Package inamik-tableformatter (orphan) Package javacsv (orphan) Package jopt-simple (orphan) Package libdrizzle (orphan) Package libgnomecups (orphan) Package libindicator (orphan) comaintained by: jspaleta Package libopensync-plugin-sunbird (orphan) comaintained by: awjb Package lx (orphan) Package mimetic (orphan) Package mingw-openjpeg (orphan) comaintained by: epienbro Package mlmmj (orphan) Package mtpfs (orphan) Package nagios-plugins-rhev (fails to build) Package ncpfs (orphan) Package nitrogen (orphan) Package notification-daemon (orphan) Package obapps (orphan) Package ocaml-cmigrep (orphan) Package pbm2l2030 (orphan) Package pbm2l7k (orphan) Package pclock (orphan) Package perl-Bio-Graphics (orphan) comaintained by: alexlan Package perl-Fedora-Bugzilla (orphan) comaintained by: mmaslano Package perl-bioperl (orphan) comaintained by: alexlan Package perl-bioperl-run (orphan) comaintained by: alexlan Package pidgin-gfire (orphan) Package polkit-gnome (orphan) Package python-GeoIP (orphan) Package python-chm (orphan) Package python-drizzle (orphan) Package python-wsgi-jsonrpc (orphan) Package rubygem-acts-as-list (orphan) Package spicebird (orphan) Package sympy (orphan) Package trac-agilo-plugin (orphan) comaintained by: kevin Package util-vserver (orphan) Package vdr-skins (orphan) Package vdr-text2skin (orphan) Package vdr-wapd (orphan) Package volpack (orphan) Package wmSun (orphan) Package wmbinclock (orphan) Package wmblob (orphan) Package wmcalc (orphan) Package wmcore (orphan) Package wmcube (orphan) Package wmdrawer (orphan) Package wmeyes (orphan) Package wmnet (orphan) Package wmpuzzle (orphan) Package wmsystemtray (orphan) Package wmtictactoe (orphan) Package wmtop (orphan) Package wmwave (orphan) Package wmweather (orphan) Package xml-writer (orphan) List of deps left behind by packages which are orphaned or fail to build: Removing: bamf bamf-qt requires bamf-devel = 0.2.104-4.fc18 gnome-pie requires libbamf3.so.0 gnome-pie requires bamf3-devel = 0.2.104-4.fc18 Removing: bouncycastle-tsp itext requires bouncycastle-tsp = 1.46-6.fc19 itext-core requires bouncycastle-tsp = 1.46-6.fc19 Removing: c2050 printer-filters requires c2050 = 0.3b-7.fc19 Removing: c2070 printer-filters requires c2070 = 0.99-10.fc19 Removing: certmaster func requires certmaster = 0.28-5.fc19 Removing: gmyth gstreamer-plugins-bad-free requires gmyth-devel = 0.7.1-20.fc19 gstreamer-plugins-bad-free-extras requires libgmyth.so.0 Removing: jopt-simple springframework requires jopt-simple = 3.3-8.fc19 Removing: libgnomecups libgnomeprint22 requires libgnomecups-1.0.so.1 libgnomeprint22 requires libgnomecups-devel = 0.2.3-12.fc18 Removing: lx printer-filters requires lx = 20030328-9.fc19 Removing: ncpfs medusa requires libncp.so.2.3 medusa requires ncpfs-devel = 2.2.6-18.fc19 medusa requires libncp.so.2.3(NCPFS.2.2.0.17) medusa requires libncp.so.2.3(NCPFS_2.2.0.19) medusa requires libncp.so.2.3(NCPFS_2.2.1) Removing: notification-daemon gnome-session requires notification-daemon = 0.7.6-2.fc19 notification-daemon-engine-nodoka requires notification-daemon = 0.7.6-2.fc19 Removing: pbm2l2030 printer-filters requires pbm2l2030 = 1.4-10.fc19 Removing: pbm2l7k printer-filters
Re: Non responsive state for systemd
Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. Quick check with pstack 1: #0 0x7fe7f949d3d0 in __pause_nocancel () from /lib64/libc.so.6 #1 0x7fe7fb11fe6d in freeze () #2 0x7fe7fb0c6d9c in crash () #3 signal handler called #4 0x7fe7f91a8601 in pcre_exec () from /lib64/libpcre.so.1 #5 0x7fe7fac7446c in lookup () from /lib64/libselinux.so.1 #6 0x7fe7fac6d764 in selabel_lookup_common () from /lib64/libselinux.so.1 #7 0x7fe7fac6db9b in selabel_lookup_raw () from /lib64/libselinux.so.1 #8 0x7fe7fb10cab7 in label_mkdir () #9 0x7fe7fb10cfc4 in makedir_parents () #10 0x7fe7fb10c091 in cg_create () #11 0x7fe7fb100f38 in cgroup_bonding_realize () #12 0x7fe7fb101011 in cgroup_bonding_realize_list () #13 0x7fe7fb0f2433 in exec_spawn () #14 0x7fe7fb0d74a2 in service_spawn () #15 0x7fe7fb0da6f7 in service_enter_start () #16 0x7fe7fb0dacf8 in service_start () #17 0x7fe7fb131209 in job_run_and_invalidate () #18 0x7fe7fb0c9566 in manager_dispatch_run_queue () #19 0x7fe7fb0cbd00 in manager_loop () #20 0x7fe7fb0c48ae in main () Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, Mar 4, 2013 at 1:18 PM, Miloslav Trmač m...@volny.cz wrote: This is a proposal of changes to the way future Fedora cycles should work and integrate changes. Some of the things we want to achieve: * Make rawhide to be reliably installable and usable by developers by coherently introducing changes. * Define the interfaces that applications can rely on (and by inference, the ones that they can't). * Ensure that functionality implemented in Fedora doesn't unintentionally regress, and provide a clear way to change or replace earlier implementations. To do this, we propose to specify three levels of stability we attempt. These are defined at the level of interfaces (e.g. specific library/command/file), not at the level of packages: 1: Long-term ABI for applications that we don't want to break without significant discussion. For now, this will include the stable kernel and libc ABIs Please define what you mean by stable kernel ABI. Do you mean the kernel - userspace syscall ABI? If you mean anything other than that I really don't think it's going to work. There is no internal stable kernel ABI and upstream is very against having one. Put another way: There is no way Fedora is doing anything like kABI. 2: Base design: A set of functionality that was implemented and needs to be kept working in any composed tree, including rawhide; may include specific commands. Behavior that other parts of the distribution depends on. Functionality accepted for this tier by FESCo using the planning process, and some interfaces this functionality relies on. Isn't this basically just critpath? Why is it being called something new? Or if it isn't just critpath, can you explain how it is different? 3: Internal API: we'll do our best not to change it within a release lifetime; basically the existing Fedora compatibility and update rules. e.g. Python/Perl/Ruby X.Y version, most library interfaces, and major aspects of UI. Just to be clear, when you stay within a release you mean after it is actually released? Or do you mean after it's branched? Clearly not rawhide or we'd never update anything, but at what point is this in effect? We also propose to build up automated tests to verify the tier 1 and tier 2 functionality, and use those tests on newly-built packages to gate inclusion in rawhide. Finally, the planning process will recognize the existence of these tiers by classifying each proposed change: * Changes to tiers 1 and 2: Strong recommendation that new stable APIs have new tests delivered at approximately the same time, if possible. This benefits change owners by diminishing the risk of accidental breakage of the functionality. Existing tests for the functionality must be updated at the same time as well. Waivers may be requested of FESCo. Are you envisioning the package maintainers to have to write these tests if they don't exist upstream? * Complex changes not affecting tiers 1/2 (e.g., new core library version): Strong recommendation that landing of these be coordinated, via the use of side tags or similar features. We already encourage this today, correct? So this is just a formalization of that. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-SFTP-Foreign/f17] Removing dependency that breaks builds
Summary of changes: 2ad89e3... Removing dependency that breaks builds (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: GNOME 3.7.91
On Mon, 2013-03-04 at 15:18 +, Richard Hughes wrote: If you're planning on doing a 3.7.91 build manually (i.e. that's not picked up by mclazy, or one you'd rather do on your own), can you add them to the spreadsheet please: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc This way we can QA and test the release and push it in one go. I'll also be putting links to build failures on the same sheet. Thanks. Hi, is it branched already? My packages doesn't seem to be branched yet, thus no need for the giant update, only a rawhide build is done. Or, do you want to write them down regardless of branching for f19? Bye, Milan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Mon, Mar 4, 2013 at 11:20 AM, Bill Nottingham nott...@redhat.com wrote: Package sympy (orphan) I have taken ownership of sympy. -- Jerry James http://www.jamezone.org/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: iptables 1.4.10 update, libxtables so version bump
On Mon, Mar 04, 2013 at 06:44:43PM +0100, Thomas Woerner wrote: Hello, iptables has been updated in Fedora rawhide. The version of libxtables has been bumped to 10. Therefore all packages, that require libxtables need to be rebuilt for the new lib. iproute has been rebuilt already. There are also testing packages for F-18: https://admin.fedoraproject.org/updates/iproute-3.6.0-7.fc18,iptables-1.4.18-1.fc18 Affected Fedora packages: libguestfs Thanks -- I'm about to release a new version of libguestfs (probably tomorrow) so I'll rebuild it at the same time. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: iptables 1.4.10 update, libxtables so version bump
Am 04.03.2013 18:44, schrieb Thomas Woerner: Hello, iptables has been updated in Fedora rawhide. The version of libxtables has been bumped to 10. Therefore all packages, that require libxtables need to be rebuilt for the new lib. iproute has been rebuilt already. There are also testing packages for F-18: https://admin.fedoraproject.org/updates/iproute-3.6.0-7.fc18,iptables-1.4.18-1.fc18 Affected Fedora packages: libguestfs perl-IPTables-libiptc thank you! - koji is my friend :-) installed a hour ago on my workstation and homeserver (Fedora 18) for me all is working fine, i only need to reboot for whatever reason after restart iptables.service to get my SIP phone connected again to our companys asterisk, strange because my android phone was fine behind the NAT on hostapd, but OK * firewall works * NAT works * NAT/Masquerading between different openvpn-networks works * port-forwarding works [root@srv-rhsoft:~]$ rpm -qa | grep iptables iptables-services-1.4.18-1.fc18.x86_64 iptables-1.4.18-1.fc18.x86_64 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Kernel 3.6.10-2.fc17.x86
Hello I'm looking old kernel from FC17 updates kernel-3.6.10-2.fc17.x86.rpm, where I can find it? All 3.7.9-X kernels have broken IPv6 support. They crashes when native IPv6 is big - for example during amanda backup running via IPv6. Thank You. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.6.10-2.fc17.x86
On Mon, Mar 4, 2013 at 2:13 PM, Lukasz Trabinski luk...@wsisiz.edu.pl wrote: Hello I'm looking old kernel from FC17 updates kernel-3.6.10-2.fc17.x86.rpm, where I can find it? In koji. http://koji.fedoraproject.org/koji/packageinfo?packageID=8 All 3.7.9-X kernels have broken IPv6 support. They crashes when native IPv6 is big - for example during amanda backup running via IPv6. Did you file a bug on that? If you have a simple testcase, we should probably get that sorted out and fixed instead of just downleveling your kernel to something with lots of other known bugs and security issues. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.6.10-2.fc17.x86
Am 04.03.2013 20:13, schrieb Lukasz Trabinski: Hello I'm looking old kernel from FC17 updates kernel-3.6.10-2.fc17.x86.rpm, where I can find it? http://koji.fedoraproject.org/koji/packageinfo?packageID=8 All 3.7.9-X kernels have broken IPv6 support. They crashes when native IPv6 is big - for example during amanda backup running via IPv6 well, you should make bugreports! all the older kernels have HUGE security bugs there is also a 3.7.10 http://koji.fedoraproject.org/koji/buildinfo?buildID=398788 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Kernel 3.6.10-2.fc17.x86
On Mon, 4 Mar 2013, Reindl Harald wrote: I'm looking old kernel from FC17 updates kernel-3.6.10-2.fc17.x86.rpm, where I can find it? http://koji.fedoraproject.org/koji/packageinfo?packageID=8 Thank You. All 3.7.9-X kernels have broken IPv6 support. They crashes when native IPv6 is big - for example during amanda backup running via IPv6 well, you should make bugreports! I will do. all the older kernels have HUGE security bugs I know, I have upgraded my all machines but one router with kernels 3.7.9-X crashes with big ipv6 traffic. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Net-SFTP-Foreign/f18] Removing dependency that breaks builds
Summary of changes: 2ad89e3... Removing dependency that breaks builds (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 917609] perl-Glib-Object-Introspection-0.015 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=917609 Daniel Berrange berra...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Resolution|--- |RAWHIDE Last Closed||2013-03-04 14:27:54 -- 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=K9D8mVqcCSa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On 4 March 2013 18:20, Bill Nottingham nott...@redhat.com wrote: Before we branch for Fedora 19, as is custom, we will block currently orphaned packages and packages that have failed to build since Fedora 17. The following packages are currently orphaned, or fail to build. If you have a need for one of these packages, please pick them up. If no one claims any of these packages, they will be blocked before we branch for Fedora 19. That is currently scheduled to happen on or around March 12. Package bouncycastle-tsp (orphan) Package ganymed-ssh2 (orphan) Package jopt-simple (orphan) I've taken these java deps. -- Mat Booth http://fedoraproject.org/get-fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer jwbo...@gmail.com wrote: 1: Long-term ABI for applications that we don't want to break without significant discussion. For now, this will include the stable kernel and libc ABIs Please define what you mean by stable kernel ABI. Do you mean the kernel - userspace syscall ABI? If you mean anything other than that I really don't think it's going to work. This means whatever the Linux kernel project says is their stable ABI. It was not at all intended to expand the ABI boundary. 2: Base design: A set of functionality that was implemented and needs to be kept working in any composed tree, including rawhide; may include specific commands. Behavior that other parts of the distribution depends on. Functionality accepted for this tier by FESCo using the planning process, and some interfaces this functionality relies on. Isn't this basically just critpath? Why is it being called something new? Or if it isn't just critpath, can you explain how it is different? * Critical path is a set of packages; this is a set of functionality/interfaces. * Tier 2 may include both both user-visible aspects and programming interfaces. * Tiers 1 and 2 are expected to be kept working (as primarily verified by the tests) even in rawhide. * Changes to tiers 1 and 2 are required to go through the planning process. A few possible examples of how this could work (without necessarily claiming that all of these things should be in tier 2, that's up to maintainers and FESCo): * /bin/bash is an important part of the CLI, and any package build that breaks it would not be accepted into rawhide (modulo possible temporary waivers for merging a change). OTOH broken /usr/bin/bashbug, missing info documentation, or other less important aspects of the package would not prevent rawhide inclusion. * The polkit D-Bus API is an important cross-package interface, and any package build that breaks applications using it would not be accepted into rawhide. * Since F18 we have https://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop , and any update that reverts that would not be accepted into rawhide. NOTE: In all of these cases, the situation is NOT set in stone - incompatible changes to the functionality in tier 2 can happen, can even happen in every Fedora release. The only hard requirements are that the change must go through the Planning process and be acked by FESCo, and that existing tests must be updated. 3: Internal API: we'll do our best not to change it within a release lifetime; basically the existing Fedora compatibility and update rules. e.g. Python/Perl/Ruby X.Y version, most library interfaces, and major aspects of UI. Just to be clear, when you stay within a release you mean after it is actually released? Or do you mean after it's branched? Clearly not rawhide or we'd never update anything, but at what point is this in effect? Basically the existing Fedora compatibility and update rules: http://fedoraproject.org/wiki/Updates_Policy Finally, the planning process will recognize the existence of these tiers by classifying each proposed change: * Changes to tiers 1 and 2: Strong recommendation that new stable APIs have new tests delivered at approximately the same time, if possible. This benefits change owners by diminishing the risk of accidental breakage of the functionality. Existing tests for the functionality must be updated at the same time as well. Waivers may be requested of FESCo. Are you envisioning the package maintainers to have to write these tests if they don't exist upstream? Yes. My personal opinion: * For UI and APIs, we want the things included in tier 2 to be sufficiently stable/tested, which probably means they should already have an upstream test suite; if they don't, and Fedora decides that they are important, Fedora should contribute an upstream test suite. * I expect that many change owners will find it worth their time to write a test - e.g. in the above example of Avahi it's one-time cost of writing a fairly simple test that will save manual checking and worry for the future. * Complex changes not affecting tiers 1/2 (e.g., new core library version): Strong recommendation that landing of these be coordinated, via the use of side tags or similar features. We already encourage this today, correct? So this is just a formalization of that. Yes, this has even been accepted by FESCo (last sentence of https://fedoraproject.org/wiki/User:Mmaslano/Feature_process , in https://fedorahosted.org/fesco/ticket/896). So this is just a matter of making it possible/easy, and making it actually happen. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Amide, looking for a co-maintainer
On Mon, 4 Mar 2013 17:43:32 + Mat Booth fed...@matbooth.co.uk wrote: On 4 March 2013 17:33, Mario Ceresa mrcer...@gmail.com wrote: Hi all, I noticed that Amide is orphaned, even if it is still possible to install in f18. Is anyone interested in helping to maintain it? Thanks, Mario BTW: I tried to take ownership, but I can only do that for 17. Is there something wrong with my FAS account? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel It looks like the package was retired (perhaps mistakenly - there is no dead.package file) for f18 and devel, which is why you cannot take ownership of it for those branches. This package was retired back in the f15 timeframe, so it needs a new review to bring it back. You might ask the former maintainer why they dropped it: http://lists.fedoraproject.org/pipermail/scm-commits/2011-February/566745.html kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Mon, Mar 4, 2013 at 6:01 PM, Andy Gospodarek agosp...@redhat.com wrote: On Mon, Mar 04, 2013 at 10:19:14AM -0600, Matt Domsch wrote: drivers/net/ethernet/mellanox/mlx4/en_netdev.c: dev-dev_id = port - 1; drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; of these, both the mlx4 and siena drivers set them starting at 0. I think the fec driver might be doing so as well, but it's not as obvious. I'm pretty sure cxgb4 starts numbering at 1 just from reading the code. So, as-is in the 3.9rc1 kernel, I wouldn't be comfortable relying on the value of dev_id. I agree it looks like some cleanup is needed due to the inconsistency. This is still only an issue when a single function supports multiple ethernet devices, right? I believe so, yes. Ok, good. I did like your idea to possibly set this to something other than 0 in the default case and then make sure that any driver that needs to set it can do so. The udev code just appends the dev_id number to the device name if dev_id is 0, so either starting at 0 or at 1 would work fine and produce reliable results. Starting at 1 would create slightly more consistent names, where all names of one and the same card follow the same scheme, and 0 is not special because it is suppressed. Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, Mar 04, 2013 at 08:35:08PM +0100, Miloslav Trmač wrote: On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer jwbo...@gmail.com wrote: 1: Long-term ABI for applications that we don't want to break without significant discussion. For now, this will include the stable kernel and libc ABIs Please define what you mean by stable kernel ABI. Do you mean the kernel - userspace syscall ABI? If you mean anything other than that I really don't think it's going to work. This means whatever the Linux kernel project says is their stable ABI. It was not at all intended to expand the ABI boundary. The only really guaranteed stable ABI the kernel exports is the syscall/ioctl interface, and to a lesser extent the proc/sysfs ABI. Kernels in rawhide do differ from what we end up shipping in releases, because they are continually rebased during the merge window/rc phase, wherein it's entirely possible that a new interface is refined. We've had situations for example where a new syscall added during the merge window has had additional parameters added/existing ones changed during -rc phase. This hasn't been a problem because typically, nothing relies upon an interface in unreleased kernels, but we need to make it clear here that nothing in new interfaces is frozen until a .0 release, in case people start thinking you shipped it in rawhide, so it must be stable. Dave -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
no luakit on fc18
There is no luakit on fc18 . how to help ? https://admin.fedoraproject.org/pkgdb/applications/Luakit?_csrf_token=a4b62ea58e444602602d35ee0a3f33e6d8980887 -- Klearchos-Angelos Gkountras kleag...@gmail.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
David Highley wrote: Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. Quick check with pstack 1: #0 0x7fe7f949d3d0 in __pause_nocancel () from /lib64/libc.so.6 #1 0x7fe7fb11fe6d in freeze () #2 0x7fe7fb0c6d9c in crash () #3 signal handler called #4 0x7fe7f91a8601 in pcre_exec () from /lib64/libpcre.so.1 #5 0x7fe7fac7446c in lookup () from /lib64/libselinux.so.1 #6 0x7fe7fac6d764 in selabel_lookup_common () from /lib64/libselinux.so.1 #7 0x7fe7fac6db9b in selabel_lookup_raw () from /lib64/libselinux.so.1 #8 0x7fe7fb10cab7 in label_mkdir () #9 0x7fe7fb10cfc4 in makedir_parents () #10 0x7fe7fb10c091 in cg_create () #11 0x7fe7fb100f38 in cgroup_bonding_realize () #12 0x7fe7fb101011 in cgroup_bonding_realize_list () #13 0x7fe7fb0f2433 in exec_spawn () #14 0x7fe7fb0d74a2 in service_spawn () #15 0x7fe7fb0da6f7 in service_enter_start () #16 0x7fe7fb0dacf8 in service_start () #17 0x7fe7fb131209 in job_run_and_invalidate () #18 0x7fe7fb0c9566 in manager_dispatch_run_queue () #19 0x7fe7fb0cbd00 in manager_loop () #20 0x7fe7fb0c48ae in main () Another piece of information is: Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused This messages comes from any attempt to use systemctl. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review swaps!
On 03/04/2013 11:16 AM, Peter Lemenkov wrote: Hello All! I've got few review requests which got stuck for a while, and I'd love to trading reviews with anyone. * https://bugzilla.redhat.com/906473 - erlang-ranch - Socket acceptor pool for TCP protocols * https://bugzilla.redhat.com/906481 - erlang-cowboy - Small, fast, modular HTTP server written in Erlang * https://bugzilla.redhat.com/906482 - erlang-mimetypes - Erlang MIME types library * https://bugzilla.redhat.com/906486 - erlang-parsexml - Simple DOM XML parser with convenient and very simple API Please help me to add them to Fedora, and I'll help you in return! I'll take a look at erlang-ranch and would appreciate it if you could take a look at my review request here https://bugzilla.redhat.com/show_bug.cgi?id=855529 Best regards, Jos. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
OK to bump soname for a lesser-used library?
It's clear to me that library soname bumps should generally be avoided in released Fedoras, but can it be allowed for more fringe libraries? Specifically, I'd like to get Dyninst 8.1 into Fedora 18, which would bump everything from .so.8.0 to .so.8.1. The only in-distro package that BuildRequires Dyninst is SystemTap, which I also co-maintain and will certainly rebuild in tandem. If there are any out-of-distro users of our dyninst libraries, I expect they are of the more research-oriented type who will appreciate keeping up the version. I suppose any such people should speak up, please, if you disagree. So given that this library's use is pretty well contained, might it be OK to go ahead and update in F18? Thanks, Josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: OK to bump soname for a lesser-used library?
Hi On Mon, Mar 4, 2013 at 5:07 PM, Josh Stone wrote: If there are any out-of-distro users of our dyninst libraries, I expect they are of the more research-oriented type who will appreciate keeping up the version. I suppose any such people should speak up, please, if you disagree. So given that this library's use is pretty well contained, might it be OK to go ahead and update in F18? https://fedoraproject.org/wiki/Updates_Policy The goal is to provide stability. If the soname bump is required for security or critical bug fixes, then yes. For feature updates, generally speaking, we should avoid it but if there are compelling advantages and you are relatively confident that it is a robust change, then you can. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. I can see OpenStack upstream reacting to this by capping its required version range for each library it depends so that if the library does release an incompatible version, OpenStack sticks with the latest compatible version. If that happens, I think OpenStack packagers will need to look seriously at using Software Collections. Basically, we'd look to package and maintain our own stack of all the Python libraries we need above the core Python libraries. So, you'd have openstack-nova, openstack-glance, etc. all installed as normal in /usr, /var, etc. but they'd require python libraries from the openstack-grizzly SC like openstack-grizzly-python-eventlet which would be installed in /opt/fedora/openstack-grizzly/root/usr/lib/python. I'd appreciate it if someone else with a Fedora Python packaging background could look into this and, hopefully, explain how the discussion on distutils-sig isn't so terrifying after all. Cheers, Mark. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]]
Hey, Just forwarding it here so Python folks don't miss it on the main devel list. Thanks, Mark. Forwarded Message From: Mark McLoughlin mar...@redhat.com Reply-to: Mark McLoughlin mar...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?] Date: Mon, 04 Mar 2013 22:51:31 + On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. I can see OpenStack upstream reacting to this by capping its required version range for each library it depends so that if the library does release an incompatible version, OpenStack sticks with the latest compatible version. If that happens, I think OpenStack packagers will need to look seriously at using Software Collections. Basically, we'd look to package and maintain our own stack of all the Python libraries we need above the core Python libraries. So, you'd have openstack-nova, openstack-glance, etc. all installed as normal in /usr, /var, etc. but they'd require python libraries from the openstack-grizzly SC like openstack-grizzly-python-eventlet which would be installed in /opt/fedora/openstack-grizzly/root/usr/lib/python. I'd appreciate it if someone else with a Fedora Python packaging background could look into this and, hopefully, explain how the discussion on distutils-sig isn't so terrifying after all. Cheers, Mark. ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: Non responsive state for systemd
On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote: Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. This is a bug in libselinux: https://bugzilla.redhat.com/show_bug.cgi?id=901812 Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3.7.91
On Mon, Mar 04, 2013 at 10:06:46AM -0800, Dan Mashal wrote: On Mon, Mar 4, 2013 at 7:18 AM, Richard Hughes hughsi...@gmail.com wrote: If you're planning on doing a 3.7.91 build manually (i.e. that's not picked up by mclazy, or one you'd rather do on your own), can you add them to the spreadsheet please: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc This way we can QA and test the release and push it in one go. I'll also be putting links to build failures on the same sheet. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel gpointing-device-settings fails to build in rawhide. The code in git does not seem to be migrated to gsettings either. https://bugzilla.redhat.com/show_bug.cgi?id=914053 it was recently (about-to-be) orphaned for those reasons. http://lists.fedoraproject.org/pipermail/devel/2013-January/176964.html Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
PackageKit ordering patch
Properly order packages returned by PackageKit so automations executed on 64bit systems won't sometimes pull 32bit packages due to a lack of ordering (Jockey). -- diff -rupN PackageKit-0.6.22.orig/backends/yum/yumFilter.py PackageKit-0.6.22/backends/yum/yumFilter.py --- PackageKit-0.6.22.orig/backends/yum/yumFilter.py2012-12-19 14:39:41.148069422 -0500 +++ PackageKit-0.6.22/backends/yum/yumFilter.py 2012-12-19 14:56:49.163672753 -0500 @@ -88,6 +88,8 @@ class YumFilter(PackagekitFilter): if (base, version) not in base_list_already_got: output_list.append((pkg, status)) base_list_already_got.append ((base, version)) +output_list.sort() +output_list.reverse() return output_list def _do_newest_filtering(self, pkglist): @@ -116,6 +118,8 @@ class YumFilter(PackagekitFilter): del newest[key] newest[key] = (pkg, state) +newest.values().sort() +newest.values().reverse() return newest.values() def post_process(self): @@ -127,6 +131,8 @@ class YumFilter(PackagekitFilter): if FILTER_NEWEST in self.fltlist: self.package_list = self._do_newest_filtering(self.package_list) +self.package_list.sort() +self.package_list.reverse() return self.package_list def _pkg_compare(self, pkg1, pkg2): -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: F16 and F18: bugzilla, bugs and EOL
Yes and no. Right, I could press two buttons and reopen ticket. No, I am not a reporter so there would be no actual result in it. If you digg into closed/dublicate reports you will see that there were some communication in them. But it stopped every time that bug been marked as dublicate. Reportes of that bugs as I think suggest that if it is a dublicate someone for sure is working on it. And it is wrong. Reporter of first bugreport just foggot already he made it. So. First bugreport has reporter why does not wont to help (what is rather often with abrt generated reports). Reporters of dublicates think that first bug is under revision and stop working on their reports (who will blame them? there reports are closed). All became into CLOSED status after F16 EOL, nothing became better. Then the original one could be reopened and version set to F18. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. It would be probably possible to check all dupes automatically but again a corner case, fixable manually (if somebody takes care). Btw. as asked frequently in the previous EOL thread and to make it easier for me and upcoming guys responsible for EOL - the script is now available in the GIT of Fedora Project Schedule hosted project [1]. Jaroslav [1] https://fedorahosted.org/fedora-project-schedule/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Non responsive state for systemd
Lennart Poettering wrote: On Mon, 04.03.13 10:24, David Highley (dhigh...@highley-recommended.com) wrote: Lennart Poettering wrote: On Mon, 04.03.13 07:56, David Highley (dhigh...@highley-recommended.com) wrote: Twice now we have one Fedora 18 system where systemd seems to get into a non responsive state. We are not able to get the status of any service and we're not able to do an init 6 to restart the system. Did notice today that a full process list showed a message about abrt and something to the effect nobody cared. We also see a number of defunct processes that seem to never clear. So far the only remedy we have found is a hard power cycle. Can you get a stack trace of PID1? sudo pstack 1 should already give a hint, but even better would be a a bt full via gdb. We are offsite right now so will dig deeper later. We had checked the log files and noticed that it complains about rsyncd not being able to connect to a port and there was another complaint about Gnome. The rsync one repeats as there are back ups that are not being serviced which is is what alerted to something being wrong. We are sending and receiving email from this system. It also has an internal web, mysql, and other subsystems which seem to work fine. So when this state occurs it sometimes takes a while to notice. This is a bug in libselinux: https://bugzilla.redhat.com/show_bug.cgi?id=901812 Nasty regression bug and it must not be consistent as it only happens on one of our systems, knock on wood, so far. Yes, the last thing we had done was turn off an selinux bool that was a work around until an update came out to fix it yesterday. Unlike the bug report which indicates you can to a sync reboot, nothting but the power switch gets this system out of the issue. We hope there is a fix for this soon. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GNOME 3.7.91
On Mon, Mar 4, 2013 at 4:35 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Mon, Mar 04, 2013 at 10:06:46AM -0800, Dan Mashal wrote: On Mon, Mar 4, 2013 at 7:18 AM, Richard Hughes hughsi...@gmail.com wrote: If you're planning on doing a 3.7.91 build manually (i.e. that's not picked up by mclazy, or one you'd rather do on your own), can you add them to the spreadsheet please: https://docs.google.com/spreadsheet/ccc?key=0AtzJKpbiGX1zdGJzeU9waFJFZmgyQzBuN2VxU0lxbHc This way we can QA and test the release and push it in one go. I'll also be putting links to build failures on the same sheet. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel gpointing-device-settings fails to build in rawhide. The code in git does not seem to be migrated to gsettings either. https://bugzilla.redhat.com/show_bug.cgi?id=914053 it was recently (about-to-be) orphaned for those reasons. http://lists.fedoraproject.org/pipermail/devel/2013-January/176964.html Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Technically, it is fixable without too much hard work. I spoke with Ray and I'll hold on to the package for a little while longer but will probably retire/block it. mate-control-center is supposed to have this functionality but I'm not seeing it. Either way, it would still be useful for other DEs. It has some settings that mousetweaks and control center do not. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Mon, 4 Mar 2013 20:35:08 +0100 Miloslav Trmač m...@volny.cz wrote: On Mon, Mar 4, 2013 at 7:50 PM, Josh Boyer jwbo...@gmail.com wrote: ...snip... Finally, the planning process will recognize the existence of these tiers by classifying each proposed change: * Changes to tiers 1 and 2: Strong recommendation that new stable APIs have new tests delivered at approximately the same time, if possible. This benefits change owners by diminishing the risk of accidental breakage of the functionality. Existing tests for the functionality must be updated at the same time as well. Waivers may be requested of FESCo. Are you envisioning the package maintainers to have to write these tests if they don't exist upstream? Yes. Are these tests that run as part of package build? Or are we talking something like autoqa tests? Or ? My personal opinion: * For UI and APIs, we want the things included in tier 2 to be sufficiently stable/tested, which probably means they should already have an upstream test suite; if they don't, and Fedora decides that they are important, Fedora should contribute an upstream test suite. * I expect that many change owners will find it worth their time to write a test - e.g. in the above example of Avahi it's one-time cost of writing a fairly simple test that will save manual checking and worry for the future. How is this gating to rawhide going to work? Or that's yet to be determined? While I like the idea overall, I think the devil will be in the details here. :) If we make the tests too strict, we are going to slow things down, if we make them too manual we push more work on rel-eng, if we don't make them strict enough, we have what we have today, but with more red tape. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: no luakit on fc18
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/03/13 03:26, Klearchos-Angelos Gkountras wrote: There is no luakit on fc18 . how to help ? https://admin.fedoraproject.org/pkgdb/applications/Luakit?_csrf_token=a4b62ea58e444602602d35ee0a3f33e6d8980887 It's orphaned, so if you're a packager, feel free to take it up: https://admin.fedoraproject.org/pkgdb/acls/name/luakit - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRNY5UAAoJEEr1VKujapN69VsH/1k8KW0RARmnqo8YZVmO9go2 vkY/NVgiMIyRS80injskpVaW8c/Vy9dJLTt/8XQl/387iZ4IiAmpLiZUkUZMl5TN rhi4BHfbsCx6XHhpLCNe1N/CPGk6ICjyEwALuaN5bKRTIhcORn+xFxk36nxY+uOy MpcpQWWZijiuriIgvwArHcU1bIfyPvkwQjmEvo86DoKQKLQ8FKlRp6OYLquucTrG R7iZXyC33VbV0efCHNdFWUZN00pl/rj11xnLj6EzByjlcgSTEXjLEwM/bqf/w9Fa UvJ4Bwe+TCLtK5Or4W6/kFergSiaUvD4Low5wkVv+CwwQ9IrTA1SEqMYTPq9ifs= =kg3B -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247
Am Dienstag, den 05.03.2013, 03:56 + schrieb Rahul Sundaram:
commit 0ed4b2cddfa74be4b66b3646aee4c5d0e3fe756f
Author: Rahul Sundaram sunda...@fedoraproject.org
Date: Mon Mar 4 22:55:58 2013 -0500
remove vendor tag from desktop file.
https://fedorahosted.org/fpc/ticket/247
- drop obsolete conditionals and version requirements
- drop INSTALL file
- clean up spec to follow current guidelines
Hi Rahul,
if you want to help out in the effort to remove the vendor tags, please
do it *right*. That means:
* use conditionals, so maintainers can continue to use one spec
for F19 and other releases. Toshio provided examples at
https://fedoraproject.org/wiki/User:Toshio/Devendorize_desktop_files
* Don't rewrite spec files for no reason. There was no reason to
break compatibility with older releases such as el5.
* Don't use current guidelines to justify our changes.
Everything you changed were may or should items, but our
guidelines nowhere say that one *must not* have backwards
compatibility.
While I appreciate your efforts to help out in the de-vendorization, I
think the way *how* you did it is counterproductive and causes more work
for maintainers.
As I am currently very busy with my dayjob, I'd like to ask you to
please fix all of my packages you changed to use conditionals, so I can
continue to use one spec at least for all supported Fedora releases.
Kind regards,
Christoph
emelfm2.spec | 64 ++---
1 files changed, 16 insertions(+), 48 deletions(-)
---
diff --git a/emelfm2.spec b/emelfm2.spec
index d0898ec..39a3a9c 100644
--- a/emelfm2.spec
+++ b/emelfm2.spec
@@ -1,11 +1,6 @@
-## Rebuild options:
-# --with hal : Build with hal support (default: without)
-# use bcond_without to change the default
-%bcond_with hal
-
Name: emelfm2
Version:0.8.2
-Release:2%{?dist}
+Release:3%{?dist}
Summary:File manager that implements the popular two-pane design
Group: Applications/File
@@ -14,36 +9,18 @@ URL:http://emelfm2.net/
Source0:http://emelfm2.net/rel/%{name}-%{version}.tar.bz2
#VCS svn:http://svn.emelfm2.net/trunk/
Patch0: emelfm2-0.7.1-dsofix.patch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u}
-n)
BuildRequires: dbus-glib-devel
BuildRequires: file-devel
-BuildRequires: gtk2-devel = 2.6.0
+BuildRequires: gtk2-devel
BuildRequires: libacl-devel
BuildRequires: gettext
BuildRequires: desktop-file-utils
Requires: findutils = 4.2, grep, sed, bzip2
-%if %{with hal}
-BuildRequires: hal-devel, dbus-glib-devel
-Requires: hal
-%endif
-
-# only available in Fedora = 11
-%if 0%{?fedora} 10
-BuildRequires: gtkspell-devel = 2.0.14
-%endif
-
-# Fedora 13 uses udisks
-%if 0%{?fedora} 12 || 0%{?rhel} 6
+BuildRequires: gtkspell-devel
BuildRequires: udisks-devel
Requires: udisks
-%else
-# Fedora 11 uses DeviceKit
-%if 0%{?fedora} 10
-BuildRequires: DeviceKit-disks-devel
-Requires: DeviceKit-disks
-%endif
-%endif
+
%description
emelFM2 is the GTK+2 port of emelFM. emelFM2 is a file manager that
implements
@@ -76,24 +53,15 @@ make %{?_smp_mflags} \
WITH_TRANSPARENCY=1 \
WITH_KERNELFAM=1 \
USE_INOTIFY=1 \
-%if 0%{?fedora} 10 || 0%{?rhel} 6
- EDITOR_SPELLCHECK=1 \
-%endif
+EDITOR_SPELLCHECK=1 \
WITH_OUTPUTSTYLES=1 \
WITH_CUSTOMMOUSE=1 \
WITH_GTK2=1 \
NEW_COMMAND=1 \
-%if 0%{?fedora} 11 || 0%{?rhel} 6
- WITH_UDISKS=1 \
-%endif
-%if %{with hal}
- WITH_HAL=1 \
-%endif
+WITH_UDISKS=1 \
WITH_TRACKER=1 \
WITH_ACL=1 \
-%if 0%{?fedora} 11 || 0%{?rhel} 6
- WITH_POLKIT=1 \
-%endif
+WITH_POLKIT=1 \
PREFIX=%{_prefix} \
BIN_DIR=%{_bindir} \
LIB_DIR=%{_libdir} \
@@ -106,7 +74,6 @@ make %{?_smp_mflags} \
%install
-rm -rf %{buildroot}
make install install_i18n \
DOCS_VERSION=1 \
PREFIX=%{buildroot}%{_prefix} \
@@ -119,30 +86,31 @@ make install install_i18n \
%find_lang %{name}
-desktop-file-install --vendor fedora\
+desktop-file-install \
--dir ${RPM_BUILD_ROOT}%{_datadir}/applications \
---delete-original \
${RPM_BUILD_ROOT}%{_datadir}/applications/%{name}.desktop
-
-%clean
-rm -rf %{buildroot}
-
+rm -f ${RPM_BUILD_ROOT}%{_docdir}/%{name}-%{version}/INSTALL
%files -f %{name}.lang
-%defattr(-,root,root,-)
%doc docs/ACTIONS docs/CONFIGURATION docs/CREDITS docs/HACKING
%doc docs/NEWS docs/README docs/TODO docs/USAGE docs/WARNING
%doc docs/GPL docs/LGPL
%{_bindir}/%{name}
%{_libdir}/%{name}/
-%{_datadir}/applications/fedora-%{name}.desktop
Re: Python libraries and backwards compat [was Re: What would it take to make Software Collections work in Fedora?]
- Original Message - On Thu, 2012-12-06 at 07:06 -0800, Adam Williamson wrote: On Thu, 2012-12-06 at 15:30 +0100, Nicolas Mailhot wrote: IMHO use of software collections is a symptom of a badly run organisation not devoting enough cycles to maintain the software it uses, and hoping (as in wishful thinking) no problem will go critical before the product they built on top of those collections is end-of-lifed I completely fail to see how entities with that problem will manage to maintain the package number explosion creating software collections will induce. On the one hand, I agree completely - I think the 'share all dependencies dynamically' model that Linux distros have traditionally embraced is the right one, and that we're a strong vector for spreading the gospel when it comes to that model, and it'd be a shame to compromise that. On the other hand, we've been proselytizing the Java heretics for over a decade now, and the Ruby ones for a while, and neither shows any signs of conversion or just plain going away, so we may have to call it an ecumenical matter and deal with their models somehow. Sucky as it may be. I don't know, I'm a bit conflicted. It's interesting that you call out Java and Ruby folks as being heretics. I guess that means all is kosher with Python? Python makes it a bit hard to install and use multiple parallel versions of libraries with just setuptools/distutils, so it's a bit more kosher :) Since I do both Ruby and Python packaging and I can compare them, it seems to me that the biggest difference is that Python folks aren't used to do specific version requirements (not judging what pros and cons that brings). OpenStack is getting burned by API instability in some Python packages, so I've started a thread on Python's distutils-sig to try and guage the level of heresy amongst Python folks :) It started here: http://mail.python.org/pipermail/distutils-sig/2013-February/020030.html and now we're talking about Software Collections here: http://mail.python.org/pipermail/distutils-sig/2013-March/020074.html Two things I'm picking up from the thread: - A trend towards semantic versioning and, implicit in that, an acceptance of API breakages so long as the major number of a library version is incremented - Supporting the parallel installation of incompatible versions of libraries isn't seen as an issue because you can just use virtual environments ... which amounts to Python Software Collections. The combination of those two things suggests to me that the Python world will start looking a lot less sane to packagers - i.e. library maintainers breaking API compatibility more often and assuming we can just use SC or similar to have multiple incompatible versions installed. I can see OpenStack upstream reacting to this by capping its required version range for each library it depends so that if the library does release an incompatible version, OpenStack sticks with the latest compatible version. There have been similar issues with distro-packaging of Ruby applications using bundler for quite a while now [1], [2], so it's not something unseen. If that happens, I think OpenStack packagers will need to look seriously at using Software Collections. Basically, we'd look to package and maintain our own stack of all the Python libraries we need above the core Python libraries. So, you'd have openstack-nova, openstack-glance, etc. all installed as normal in /usr, /var, etc. but they'd require python libraries from the openstack-grizzly SC like openstack-grizzly-python-eventlet which would be installed in /opt/fedora/openstack-grizzly/root/usr/lib/python. I'd appreciate it if someone else with a Fedora Python packaging background could look into this and, hopefully, explain how the discussion on distutils-sig isn't so terrifying after all. IMHO that depends how the upstreams will actually use the new functionality. It can be used both for good (better semantics of versioning making it easier for packagers to discover API changes) or bad (too tight dependencies of packages, relying on fact that users will just use venv) from Fedora's POV. Cheers, Mark. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- Regards, Bohuslav Slavek Kabrda. [1] http://lists.fedoraproject.org/pipermail/devel/2012-December/174912.html [2] http://lists.fedoraproject.org/pipermail/ruby-sig/2012-July/001073.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File IPC-Cmd-0.80.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-IPC-Cmd: 2f4c74a1c91e67dd80ef6dc5c5ebaed4 IPC-Cmd-0.80.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-IPC-Cmd] 0.80 bump
commit 6e561d7d5b3b5d366ba3566f6c8450ca88ee41df
Author: Petr Písař ppi...@redhat.com
Date: Mon Mar 4 09:28:06 2013 +0100
0.80 bump
.gitignore|1 +
perl-IPC-Cmd.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 037f637..bb5d3af 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
IPC-Cmd-0.40.tar.gz
/IPC-Cmd-0.78.tar.gz
+/IPC-Cmd-0.80.tar.gz
diff --git a/perl-IPC-Cmd.spec b/perl-IPC-Cmd.spec
index 77383b4..0e778b0 100644
--- a/perl-IPC-Cmd.spec
+++ b/perl-IPC-Cmd.spec
@@ -1,5 +1,5 @@
Name: perl-IPC-Cmd
-Version:0.78
+Version:0.80
Release:1%{?dist}
Summary:Finding and running system commands made easy
License:GPL+ or Artistic
@@ -63,5 +63,8 @@ make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 04 2013 Petr Pisar ppi...@redhat.com - 0.80-1
+- 0.80 bump
+
* Fri Feb 08 2013 Petr Pisar ppi...@redhat.com 0.78-1
- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index cb5ec5b..2624eba 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-c9379038439420228567dc3f0e34cd24 IPC-Cmd-0.78.tar.gz
+2f4c74a1c91e67dd80ef6dc5c5ebaed4 IPC-Cmd-0.80.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 917343] perl-IPC-Cmd-0.80 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=917343 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-IPC-Cmd-0.80-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-03-04 03:36:56 -- 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=5wgIIixpo4a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Perl-Critic-PetPeeves-JTRAMMELL-0.03.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Perl-Critic-PetPeeves-JTRAMMELL: 5391645f7b1e50547af8788d891437a8 Perl-Critic-PetPeeves-JTRAMMELL-0.03.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Perl-Critic-PetPeeves-JTRAMMELL] 0.03 bump
commit 3fd33215607bc4bd730b9f4ee963d67dd3786ace
Author: Petr Písař ppi...@redhat.com
Date: Mon Mar 4 09:44:15 2013 +0100
0.03 bump
.gitignore|1 +
perl-Perl-Critic-PetPeeves-JTRAMMELL.spec | 27 ++-
sources |2 +-
3 files changed, 20 insertions(+), 10 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 80ea9d1..66bbd38 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
/Perl-Critic-PetPeeves-JTRAMMELL-0.01.tar.gz
/Perl-Critic-PetPeeves-JTRAMMELL-0.02.tar.gz
+/Perl-Critic-PetPeeves-JTRAMMELL-0.03.tar.gz
diff --git a/perl-Perl-Critic-PetPeeves-JTRAMMELL.spec
b/perl-Perl-Critic-PetPeeves-JTRAMMELL.spec
index 93b9ff3..6746428 100644
--- a/perl-Perl-Critic-PetPeeves-JTRAMMELL.spec
+++ b/perl-Perl-Critic-PetPeeves-JTRAMMELL.spec
@@ -1,22 +1,30 @@
Name: perl-Perl-Critic-PetPeeves-JTRAMMELL
-Version:0.02
-Release:6%{?dist}
+Version:0.03
+Release:1%{?dist}
Summary:Policies to prohibit/require my pet peeves
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Perl-Critic-PetPeeves-JTRAMMELL/
Source0:
http://www.cpan.org/authors/id/J/JT/JTRAMMELL/Perl-Critic-PetPeeves-JTRAMMELL-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(Module::Build)
-# Tests only:
-BuildRequires: perl(Perl::Critic::Config)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+# Run-time:
+BuildRequires: perl(base)
BuildRequires: perl(Perl::Critic::Policy)
BuildRequires: perl(Perl::Critic::Utils)
+# Tests only:
+BuildRequires: perl(Exporter)
+BuildRequires: perl(lib)
+BuildRequires: perl(Perl::Critic)
+BuildRequires: perl(Perl::Critic::Config)
BuildRequires: perl(Test::More)
+# Optional tests:
BuildRequires: perl(Test::Pod) = 1.14
BuildRequires: perl(Test::Pod::Coverage) = 1.04
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-Requires: perl(Perl::Critic::Policy)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%description
Module Perl::Critic::PetPeeves::JTRAMMELL provides policies that I want
@@ -26,24 +34,25 @@ that haven't already been implemented elsewhere.
%setup -q -n Perl-Critic-PetPeeves-JTRAMMELL-%{version}
%build
-%{__perl} Build.PL installdirs=vendor
+perl Build.PL installdirs=vendor
./Build
%install
./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
%check
./Build test
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Mon Mar 04 2013 Petr Pisar ppi...@redhat.com - 0.03-1
+- 0.03 bump
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 0.02-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 276dcd8..a37a8ab 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2bf3a94cefef5e320483215e54429072 Perl-Critic-PetPeeves-JTRAMMELL-0.02.tar.gz
+5391645f7b1e50547af8788d891437a8 Perl-Critic-PetPeeves-JTRAMMELL-0.03.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SFTP-Foreign] Fixing mistake in runtime dependency
commit 11bc38c8221fcb9f06fbcb7c5722b81edac760fd
Author: Normunds Neimanis l...@rule.lv
Date: Mon Mar 4 11:02:40 2013 +0200
Fixing mistake in runtime dependency
perl-Net-SFTP-Foreign.spec |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-SFTP-Foreign.spec b/perl-Net-SFTP-Foreign.spec
index a2e107e..34ed1df 100644
--- a/perl-Net-SFTP-Foreign.spec
+++ b/perl-Net-SFTP-Foreign.spec
@@ -1,7 +1,7 @@
Name: perl-Net-SFTP-Foreign
%global real_version 1.74_05
Version: 1.74.05
-Release: 3%{?dist}
+Release: 4%{?dist}
Summary: SSH File Transfer Protocol client
Group: Development/Libraries
@@ -40,7 +40,7 @@ Requires: perl(Encode)
Requires: perl(IO::File)
Requires: perl(IO::Dir)
Requires: perl(Sort::Key)
-Requires: perl(Net::SFTP::Foreign::Unix)
+Requires: perl(Net::SFTP::Foreign::Backend::Unix)
Requires: perl(IO::Pty)
Requires: perl(Math::BigInt)
Requires: openssh-clients
@@ -88,6 +88,9 @@ make test
%changelog
+* Mon Mar 04 2013 Normunds Neimanis fedorapkg at rule.lv 1.74.05-4
+- Fixed dependency mistake
+
* Fri Mar 01 2013 Normunds Neimanis fedorapkg at rule.lv 1.74.05-3
- Added missing runtime dependencies
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SFTP-Foreign/f17] Fixing mistake in runtime dependency
Summary of changes: 11bc38c... Fixing mistake in runtime dependency (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Net-SFTP-Foreign/f18] Fixing mistake in runtime dependency
Summary of changes: 11bc38c... Fixing mistake in runtime dependency (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 877015] CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=877015 --- Comment #15 from Petr Pisar ppi...@redhat.com --- Created attachment 704881 -- https://bugzilla.redhat.com/attachment.cgi?id=704881action=edit Fix ported to perl-5.10.1 -- 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=ENQ2vEafwna=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 917609] New: perl-Glib-Object-Introspection-0.015 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=917609 Bug ID: 917609 Summary: perl-Glib-Object-Introspection-0.015 is available Product: Fedora Version: rawhide Component: perl-Glib-Object-Introspection Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 0.015 Current version in Fedora Rawhide: 0.014 URL: http://search.cpan.org/dist/Glib-Object-Introspection/ 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=gno4dSEcC5a=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 884354] CVE-2012-6329 perl: possible arbitrary code execution via Locale::Maketext
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=884354 --- Comment #12 from Petr Pisar ppi...@redhat.com --- Created attachment 704920 -- https://bugzilla.redhat.com/attachment.cgi?id=704920action=edit Fix ported to perl-5.10.1 -- 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=47rf5Nrjaca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Glib-Object-Introspection-0.015.tar.gz uploaded to lookaside cache by berrange
A file has been added to the lookaside cache for perl-Glib-Object-Introspection: c3a7f69d2748b5d2d9b9cdfc838cb1ec Glib-Object-Introspection-0.015.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Glib-Object-Introspection] Update to 0.015 release (rhbz #917609)
commit 8165fdd1719cefab390eb4d2ceebee5054a105e8
Author: Daniel P. Berrange berra...@redhat.com
Date: Mon Mar 4 12:07:42 2013 +
Update to 0.015 release (rhbz #917609)
perl-Glib-Object-Introspection.spec |5 -
sources |2 +-
2 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Glib-Object-Introspection.spec
b/perl-Glib-Object-Introspection.spec
index 413f6b4..eb9 100644
--- a/perl-Glib-Object-Introspection.spec
+++ b/perl-Glib-Object-Introspection.spec
@@ -1,6 +1,6 @@
Name: perl-Glib-Object-Introspection
-Version:0.014
+Version:0.015
Release:1%{?dist}
Summary:Dynamically create Perl language bindings
License:LGPLv2+
@@ -68,6 +68,9 @@ LANG=en_US.UTF8 make test
%{_mandir}/man3/*
%changelog
+* Mon Mar 4 2013 Daniel P. Berrange berra...@redhat.com - 0.015-1
+- Update to 0.015 release (rhbz #917609)
+
* Mon Feb 4 2013 Daniel P. Berrange berra...@redhat.com - 0.014-1
- Update to 0.014 release (rhbz #907381)
diff --git a/sources b/sources
index 3f6bd77..ea2546a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-fc1a42a89c2ef4d4e7e18bb6ae77f5b6 Glib-Object-Introspection-0.014.tar.gz
+c3a7f69d2748b5d2d9b9cdfc838cb1ec Glib-Object-Introspection-0.015.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 917669] New: Mail::Box::Parser::C parses messages with long header lines (1023 characters) improperly
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=917669 Bug ID: 917669 Summary: Mail::Box::Parser::C parses messages with long header lines (1023 characters) improperly Product: Fedora Version: 18 Component: perl-Mail-Box-Parser-C Severity: unspecified Priority: unspecified Reporter: j...@kamens.brookline.ma.us External Bug ID: CPAN 83749 Created attachment 704992 -- https://bugzilla.redhat.com/attachment.cgi?id=704992action=edit patch to fix bug Header lines longer than 1023 characters cause Mail::Box::Parser::C to parse the header improperly and corrupt the message. Yes, I realize that nothing is supposed to generate header lines that long, and yet, there are things that do, and Be generous in what you accept dictates that this could should do its best to parse them successfully. The attached patch implements a dynamic buffer for reading message lines, which is reallocated as needed to make enough space for the longest line in the mailbox, and freed when the mailbox is freed. I considered putting an upper limit on the line length to prevent memory exhaustion DoS attacks against the application running the code, but I decided not to because there is no length check on folded header lines in the existing code, which means the DoS potential is already there. I hope you will consider including this patch in Fedora whether or not the maintainer of the CPAN package releases a new version with it (I've submitted the patch to him as https://rt.cpan.org/Ticket/Display.html?id=83749). The CPAN package hasn't been modified since 2004 so there's no way of knowing whether the maintainer will fix this issue promptly. -- 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=IhFTPhl0P2a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Net-SFTP-Foreign
perl-Net-SFTP-Foreign has broken dependencies in the rawhide tree: On x86_64: perl-Net-SFTP-Foreign-1.74.05-3.fc19.noarch requires perl(Net::SFTP::Foreign::Unix) On i386: perl-Net-SFTP-Foreign-1.74.05-3.fc19.noarch requires perl(Net::SFTP::Foreign::Unix) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 877015] CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers
Product: Security Response https://bugzilla.redhat.com/show_bug.cgi?id=877015 --- Comment #16 from Petr Pisar ppi...@redhat.com --- Created attachment 705046 -- https://bugzilla.redhat.com/attachment.cgi?id=705046action=edit Fix ported to perl-5.8.8 -- 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=k0KCANuvU6a=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 917669] Mail::Box::Parser::C parses messages with long header lines (1023 characters) improperly
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=917669 --- Comment #1 from Jonathan Kamens j...@kamens.brookline.ma.us --- Actually, hold that thought. The developer is active and planning on releasing a version with a variant of my fix, and my fix has a bug in it :-), so please just consider this bug report a request to take the new version when it comes out. -- 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=uqLDL9EBa5a=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
[perl-Net-SFTP-Foreign] Removing dependency that breaks builds
commit 2ad89e35fafe225a4747098e16f9d5e9b004ebb8
Author: Normunds Neimanis l...@rule.lv
Date: Mon Mar 4 20:00:28 2013 +0200
Removing dependency that breaks builds
perl-Net-SFTP-Foreign.spec |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
---
diff --git a/perl-Net-SFTP-Foreign.spec b/perl-Net-SFTP-Foreign.spec
index 34ed1df..99b0f9a 100644
--- a/perl-Net-SFTP-Foreign.spec
+++ b/perl-Net-SFTP-Foreign.spec
@@ -1,7 +1,7 @@
Name: perl-Net-SFTP-Foreign
%global real_version 1.74_05
Version: 1.74.05
-Release: 4%{?dist}
+Release: 5%{?dist}
Summary: SSH File Transfer Protocol client
Group: Development/Libraries
@@ -40,7 +40,6 @@ Requires: perl(Encode)
Requires: perl(IO::File)
Requires: perl(IO::Dir)
Requires: perl(Sort::Key)
-Requires: perl(Net::SFTP::Foreign::Backend::Unix)
Requires: perl(IO::Pty)
Requires: perl(Math::BigInt)
Requires: openssh-clients
@@ -88,6 +87,9 @@ make test
%changelog
+* Mon Mar 04 2013 Normunds Neimanis fedorapkg at rule.lv 1.74.05-5
+- Removed dependency that brakes builds
+
* Mon Mar 04 2013 Normunds Neimanis fedorapkg at rule.lv 1.74.05-4
- Fixed dependency mistake
--
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 917669] Please update to Mail::Box::Parser::C 3.007 to fix bug: parses messages with long header lines (1023 characters) improperly
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=917669 Jonathan Kamens j...@kamens.brookline.ma.us changed: What|Removed |Added Summary|Mail::Box::Parser::C parses |Please update to |messages with long header |Mail::Box::Parser::C 3.007 |lines (1023 characters)|to fix bug: parses messages |improperly |with long header lines ||(1023 characters) ||improperly --- Comment #2 from Jonathan Kamens j...@kamens.brookline.ma.us --- 3.007 was just released. Please upgrade. -- 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=qGNuDz2577a=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[389-devel] please review: Ticket 332 - Command line perl scripts should attempt most secure connection type first
Added autobind support, and made the usage consistent across all the scripts https://fedorahosted.org/389/ticket/332 https://fedorahosted.org/389/attachment/ticket/332/0001-Ticket-332-Command-line-perl-scripts-should-attempt-.patch -- Mark Reynolds Red Hat, Inc mreyno...@redhat.com -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
