[Test-Announce] Bugzappers Meeting Agenda for 2010-03-16
Event: Fedora Bug Triage Meeting Date: 2010-03-16 Time: 15:00 UTC Location: #fedora-meeting on irc.freenode.net ** NOTE ** : Many places have gone through daylight savings time change this week: if your clock changed over the weekend, since the meeting is set according to UTC, the meeting time will have changed for you. It will be one hour later than last week. For instance, it's now 11am Eastern time and 8am Pacific time. Additions or corrections to the agenda? Reply to this email. = Agenda = * follow ups from last meeting * your item here! (let us know before the meeting) * open floor Nothing much on the agenda this week, but I'll be there in case anyone has topics to bring up. Please do come out for the meeting - it'd be great to see more faces, and we don't bite, we promise! It's a great opportunity to raise any issues you've come across while bugzapping, or ask any questions you might have. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org 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
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
There is one good update of gstreamer with include gstreamer-bad-free. And it has file conflict with gstreamer-bad of rpm-fusion and with gstreamer-good It seem to me that fedora needs a stable update policy. Go ahead Jesse Oscar Bacho P.D. I'm a user -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop app maintainers: Please check for StartupNotify=true
Could you help me to fix qtiplot? After I add StartupNotify=true to qtiplot.desktop, it times out instead of disappearing when the app window comes up under gnome2. Regards, Chen Lei On 2010-03-15 23:07:02，Colin Walters walt...@verbum.org wrote： On Mon, Mar 15, 2010 at 10:44 AM, Chen Lei supercy...@163.com wrote: Should we also add StartupWMClass=someting if StartupNotify=true doesn't work? You're going to need to elaborate on doesn't work. * You don't see a Starting... notification in the tasklist in GNOME 2? * You do, but it times out instead of disappearing when the app window comes up? * Something else? -- 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: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
On 03/16/2010 11:54 AM, Oscar Bacho wrote: 2010/3/16 Oscar Bacho ob.sys...@gmail.com mailto:ob.sys...@gmail.com There is one good update of gstreamer with include gstreamer-bad-free. And it has file conflict with gstreamer-bad of rpm-fusion and with gstreamer-good It seem to me that fedora needs a stable update policy. Go ahead Jesse Oscar Bacho P.D. I'm a user I'm on stable F12 Updates policy won't necessarily help in this case. AutoQA might but then cross repo coordination is at times tricky esp with much less people taking care of administration of third party repos. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Conflicts in latest update
hey, Trying a yum update gives me this. Broken update? Transaction Check Error: file /usr/lib64/gstreamer-0.10/libgstshapewipe.so from install of gstreamer-plugins-good-0.10.21-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/bin/gst-camera from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/bin/gst-camera-perf from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstadpcmdec.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstaiff.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstalsaspdif.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstapexsink.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstassrender.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstbayer.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstbz2.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcamerabin.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcdaudio.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcdxaparse.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstcelt.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdc1394.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdccp.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdebugutilsbad.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdirac.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstdvb.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstfestival.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstfreeze.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstfrei0r.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstgsm.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgsth264parse.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgsthdvparse.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/lib64/gstreamer-0.10/libgstid3tag.so from install of gstreamer-plugins-bad-free-0.10.18-1.fc12.x86_64 conflicts with file from package
Re: Conflicts in latest update
On Tue, Mar 16, 2010 at 12:19:56PM +0530, Ankur Sinha wrote: Trying a yum update gives me this. Broken update? Transaction Check Error: file /usr/lib64/gstreamer-0.10/libgstshapewipe.so from install of gstreamer-plugins-good-0.10.21-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/bin/gst-camera from install of If you look closer, you will notice that one of the packages comes from RPMFusion. Regards Till pgpgkzPMvc1oa.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, 2010-03-16 at 08:51 +0100, Till Maas wrote: On Tue, Mar 16, 2010 at 12:19:56PM +0530, Ankur Sinha wrote: Trying a yum update gives me this. Broken update? Transaction Check Error: file /usr/lib64/gstreamer-0.10/libgstshapewipe.so from install of gstreamer-plugins-good-0.10.21-1.fc12.x86_64 conflicts with file from package gstreamer-plugins-bad-0.10.17-2.fc12.x86_64 file /usr/bin/gst-camera from install of If you look closer, you will notice that one of the packages comes from RPMFusion. Regards Till -- hey, I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? What I'm saying is that this conflict makes users uninstall manually to proceed with the update. I use yum and know a little bit about this stuff. What about normal users who wouldn't understand why an update using a GUI is breaking? Isn't there a better way to handle whatever transition is taking place here? -- regards, Ankur - FAS : ankursinha ; franciscod @ Freenode - gpg --keyserver pgp.mit.edu --recv-keys 5E9BF638 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
Dne 16.3.2010 09:50, Ankur Sinha napsal(a): I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? There are constantly modules moving between -good, -bad, -ugly packages of gstreamer, and sometimes rpmfusion packages are not in sync with Fedora ones. Give rpmfusion packagers some time to fix it (or join them and help to fix it on your own). Matěj -- http://www.ceplovi.cz/matej/, Jabber: mceplatceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC He uses statistics as a drunken man uses lamp-posts... for support, rather than illumination. -- Andrew Lang -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Bugzilla reaction time
What are reaction time at bugzilla? I was write some commentaries at https://bugzilla.redhat.com/show_bug.cgi?id=557010 and wait for developers reaction. About one week already. Does i do something wrong or it normally? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Bugzilla reaction time
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Сергей Варюхин wrote: What are reaction time at bugzilla? - From few second to few years... I was write some commentaries at https://bugzilla.redhat.com/show_bug.cgi?id=557010 and wait for developers reaction. About one week already. Does i do something wrong or it normally? Don't worry, all ok. - -- WBR, Slavaz. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFLn3Jrb3oGR6aVLpoRAq/DAJ4sSa3P4crKMFgP/VmsPXzXEgNesgCfRS8n kdrEvQHx41tGbUHi9vhXhNI= =lER1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote: Dne 16.3.2010 09:50, Ankur Sinha napsal(a): I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? There are constantly modules moving between -good, -bad, -ugly packages of gstreamer, and sometimes rpmfusion packages are not in sync with Fedora ones. Give rpmfusion packagers some time to fix it (or join them and help to fix it on your own). I'd just add those gstreamer packages to my exclude config in yum for the moment, if you don't want to deal with the breakage each time. Then you can remove those excludes when the repos catch up with each other. /etc/yum.conf: exclude=gstreamer-plugins-bad-free gstreamer-plugins-good Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On 03/16/2010 01:37 PM, Matěj Cepl wrote: Dne 16.3.2010 13:04, Jon Masters napsal(a): I'd just add those gstreamer packages to my exclude config in yum for the moment, if you don't want to deal with the breakage each time. Then you can remove those excludes when the repos catch up with each other. /etc/yum.conf: exclude=gstreamer-plugins-bad-free gstreamer-plugins-good It's safer to use --skip-broken parameter of yum for awhile. Doesn't work in this particular case, because yum doesn't catch the file conflicts this update causes. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thorsten Leemhuis from RPMFusion said why this is the case at the FUDCon 09 in Berlin and it will continue to be the case if nothing changes: No collaboration and total underappreciation of RPMFusion's work. We cannot legally endorse RPMFusion but we could very well collaborate with them under the hood, which doesn't happen at all - at least not to my knowledge. On 03/16/2010 09:50 AM, Ankur Sinha wrote: I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkuffU0ACgkQVTRddCFHw11mVQCgv44KlLFxqfnJ6rCN33MGj4tL NBQAoKx790efBviXFZ4nkz6+RVJYVd0y =DbYv -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
Jon Masters wrote on 16.03.2010 13:04: On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote: Dne 16.3.2010 09:50, Ankur Sinha napsal(a): I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? There are constantly modules moving between -good, -bad, -ugly packages of gstreamer, and sometimes rpmfusion packages are not in sync with Fedora ones. Give rpmfusion packagers some time to fix it (or join them and help to fix it on your own). I'd just add those gstreamer packages to my exclude config in yum for the moment, if you don't want to deal with the breakage each time. Then you can remove those excludes when the repos catch up with each other. /etc/yum.conf: exclude=gstreamer-plugins-bad-free gstreamer-plugins-good There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ CU thl P.S.: A updated gst-plugins-bad package that afaik solves the problem in question was pushed to the proper RPM Fusion repos one or two hours ago, so there is no need to report a bug anymore afaics -- but people will continue to see the problem for the next ~24 hours or so due to mirror-lag and caching issues -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, 2010-03-16 at 13:45 +0100, Thorsten Leemhuis wrote: Jon Masters wrote on 16.03.2010 13:04: On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote: Dne 16.3.2010 09:50, Ankur Sinha napsal(a): I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? There are constantly modules moving between -good, -bad, -ugly packages of gstreamer, and sometimes rpmfusion packages are not in sync with Fedora ones. Give rpmfusion packagers some time to fix it (or join them and help to fix it on your own). I'd just add those gstreamer packages to my exclude config in yum for the moment, if you don't want to deal with the breakage each time. Then you can remove those excludes when the repos catch up with each other. /etc/yum.conf: exclude=gstreamer-plugins-bad-free gstreamer-plugins-good There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ CU thl P.S.: A updated gst-plugins-bad package that afaik solves the problem in question was pushed to the proper RPM Fusion repos one or two hours ago, so there is no need to report a bug anymore afaics -- but people will continue to see the problem for the next ~24 hours or so due to mirror-lag and caching issues Hey, I'm really grateful for the info. I didn't have enough knowledge on the transitions going on wrt gst packages which is why I hadn't reported a bug yet. The intention of the thread here was to get more info on what was going on. -- regards, Ankur - FAS : ankursinha ; franciscod @ Freenode - gpg --keyserver pgp.mit.edu --recv-keys 5E9BF638 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16 Mar 2010, Rex Dieter wrote: How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. Symlinks are duct-tape, why not just set it to /tmp with global rc file? Tuju -- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
Juha Tuomala wrote: On Tue, 16 Mar 2010, Rex Dieter wrote: How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. Symlinks are duct-tape, why not just set it to /tmp with global rc file? Sure, but still need to encode username into the filename (or randomize/uniq it) somehow. -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
Juha Tuomala wrote: On Tue, 16 Mar 2010, Rex Dieter wrote: How about setting that as default, away from $HOME that can be a NFS filesystem? Indeed, a solution similar to kde's ~/.kde/socket-hostname = /tmp/ksocket-username symlink is likely needed here too. Symlinks are duct-tape, why not just set it to /tmp with global rc file? fyi, tracking here, https://bugzilla.redhat.com/show_bug.cgi?id=574056 -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, 16 Mar 2010, Rex Dieter wrote: Symlinks are duct-tape, why not just set it to /tmp with global rc file? Sure, but still need to encode username into the filename (or randomize/uniq it) somehow. Could that be it: http://techbase.kde.org/KDE_System_Administration/Configuration_Files#Example:_Dynamic_Entries Tuju -- You want to throw out the baby with the bathwater! - K. Kofler Your baby is my bathwater. I don't want the OS you're building. - J. Keating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
Ankur Sinha wrote on 16.03.2010 14:33: On Tue, 2010-03-16 at 13:45 +0100, Thorsten Leemhuis wrote: Jon Masters wrote on 16.03.2010 13:04: On Tue, 2010-03-16 at 11:16 +0100, Matěj Cepl wrote: Dne 16.3.2010 09:50, Ankur Sinha napsal(a): I did notice that. I wasn't sure why a package from rpmfusion would conflict with one from fedora repos. (It's in rpmfusion for a reason) Is it being obsoleted by a fedora package (license been cleared or something)? There are constantly modules moving between -good, -bad, -ugly packages of gstreamer, and sometimes rpmfusion packages are not in sync with Fedora ones. Give rpmfusion packagers some time to fix it (or join them and help to fix it on your own). I'd just add those gstreamer packages to my exclude config in yum for the moment, if you don't want to deal with the breakage each time. Then you can remove those excludes when the repos catch up with each other. /etc/yum.conf: exclude=gstreamer-plugins-bad-free gstreamer-plugins-good There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ [...] I'm really grateful for the info. np I didn't have enough knowledge on the transitions going on wrt gst packages In case you got it wrong: my There are so many developers around on this list that know... rant was not sent in your direction ;-) which is why I hadn't reported a bug yet. The intention of the thread here was to get more info on what was going on. That's fine, but OTOH: A lot of people seem to think like that and that afaics often leads to a situation where nobody reports the bug :-/ Note that this is not specific to RPM Fusion, it's a general problem that just worse when it comes to RPM Fusion, as it only has a quite small number of contributors... CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2010 03:34 PM, Bastien Nocera wrote: Except that that's not the case here, as Benjamin and I have been in contact with Hans who takes care of the RPMFusion packages from the start. Thanks for the insight, didn't know this has changed in the meantime. - -- Alexander Kahl GNU/Linux Software Developer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkufl6sACgkQVTRddCFHw12H2QCglNDY3SzP3NfVuKsbH8V7qtUa KgEAnRbZR0awwBYFeYqKYx4O+mw7+U1k =Pmtu -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 10:54 AM, Matthias Clasen mcla...@redhat.com wrote: Any reason this cannot be an abstract socket ? Of course, then you have to check peer creds and figure out a way to communicate the socket name, but at least you don't have to worry about the usual races and permission problem you have with unix sockets. People - reliably finding other programs and initiating communication with them is 99% of the reason that DBus was created and exists in the OS. In this case, the right thing is to claim a bus name (org.blah.MyApp), export a method on it org.blah.MyApp.GetSocket, which returns the randomly-named path to your socket in /tmp. Using abstract sockets does NOT mean you don't have to worry about permissions. Any other uid can still connect to the socket, so you either need to do some sort of peer credentials if you want to restrict it to the same uid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
hal-storage-addon is now a separate package
Right now, installing hal will result in hald-addon-storage polling removable devices from boot - even if nothing's paying attention. This is a surprisingly large power consumption hit on modern systems. udisks starts the polling on-demand, which is preferable, but some legacy applications still require hal. I've just split hald-addon-storage out into its own package in rawhide. If you need the hald-addon-storage functionality (ie, you rely on hal for media change events) then please add an explicit depends on hal-storage-addon. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dual lived modules
On Mon, Mar 1, 2010 at 8:32 PM, Iain Arnell iarn...@gmail.com wrote: On Mon, Mar 1, 2010 at 9:33 PM, Chris Weyl cw...@alumni.drew.edu wrote: I originally opposed the split of the perl package into perl + sub-package for each included dual-life dist. My thinking then was that upstream is upstream, and why should we move away from what they've decided?... But in the intervening years, my perspective has changed. Having the dists as subpackages at least allows people to build rpms to override them as needed. (e.g. someone needs a newer parent, nothing intrinsically stops them from building a perl-parent package and updating their system with it.) Why not do this ourselves? Keep our core perl as it is with the separate sub-packages for modules. As and when new versions of core modules are available from the CPAN, build them as separate packages too. Initially, the separate packages are newer, so RPM will happily update from core-supplied perl-version-0.74 to separately-packaged perl-version-0.80 (or whatever). When core perl again supplies a new version, there's also no problem to upgrade from separately-packaged version to core-supplied version again (not withstanding minor complications from MODULE_COMPAT changes, epoch bumps, etc. that we have to cope with anyway). This seems to be the way we're going -- it's a reasonable choice, and I'm OK with that :) Given that our core perl package no longer makes a distinction between vendor and core, I don't think that it makes sense to package dual-lifed modules in entirely distinct packages from the core perl package. Also, as these are core, we ought to keep them close to help protect the health of core perl... Splitting them entirely will make this more difficult. Given that our core perl package no longer makes a distinction between vendor and core, I don't think that it makes sense to package dual-lifed modules solely in the core perl package! Let's follow upstream and give them a dual-life of our own. But I do agree that we should try to protect the health of the core. I'd like to extend your ideas on testing for this. Let's package the core perl test suite and require separately-packaged dual-life modules to run the entire suite in %check. Hmmm... You know. I like this :) That would go a long way to helping keep a level of consistency... And hopefully help prevent any screams of Hey! RedHat broke Perl AGAIN! from the great unwashed. * We should have a defined workflow in place to help speed the updating of the core perl package. [...snip...] or simpler, [...snip...] Sounds good to me. I was thinking we'd keep a Fedora clone of upstream Git, and maintain patches off of there, but if we're going with upstream CPAN for the dual-lifed bits, no need to do that. (Well, for this at any rate.) So, to sum up (and also pulling in points made elsewhere in this thread): * Initial dual-lifed packages will flow from perl core package * ...until they need an update, at which point standalone packages will be used to update * perl-tests off core needs to be created, and standalone packages should run perl core tests in %check after their own tests as a sanity check * core perl owner will be co-maintainer -- though I'd like to say all those with commit bits on core perl have them for the subpackages * Iain's workflow is adopted (yes? no? thoughts on Bodhi?) * dead independent dual-lifed packages will be resurrected; reviews will be done for the remaining as necessary I don't think we need any variances from the packaging gods for this, but it would probably be helpful to incorporate these bits in PackagingDrafts/Perl as we hash this out. Sound about right? -Chris -- Chris Weyl Ex astris, scientia -- 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: Akonadi's unix sockets location
On 03/16/2010 11:17 AM, Colin Walters wrote: On Tue, Mar 16, 2010 at 10:54 AM, Matthias Clasenmcla...@redhat.com wrote: Any reason this cannot be an abstract socket ? Of course, then you have to check peer creds and figure out a way to communicate the socket name, but at least you don't have to worry about the usual races and permission problem you have with unix sockets. People - reliably finding other programs and initiating communication with them is 99% of the reason that DBus was created and exists in the OS. In this case, the right thing is to claim a bus name (org.blah.MyApp), export a method on it org.blah.MyApp.GetSocket, which returns the randomly-named path to your socket in /tmp. Using abstract sockets does NOT mean you don't have to worry about permissions. Any other uid can still connect to the socket, so you either need to do some sort of peer credentials if you want to restrict it to the same uid. PLEASE do not use /tmp for communications. Use /var/run if the service is running as root, or can create a socket in /var/run. Processes running with different UID communicating over /tmp will break in a namespace environment. Evil users have successfully in the past caused privileged apps to do evil things when the priv apps do stuff in /tmp. I believe it is a good idea to avoid priv apps using any directory where random users can write. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: first reviews for dual packages
- Iain Arnell iarn...@gmail.com wrote: On Tue, Mar 16, 2010 at 9:49 AM, Marcela Maslanova mmasl...@redhat.com wrote: Hello, I've decided fix my build failure of IO::Compress::* (#555420) by updating to the latest version, which passed on my testing F-13. Please someone take a look at reviews: #573928, #573929, #573932 Not quite the first - #573826 beat you to it (by accident). But it raises an issue we've overlooked. Not all core modules have their own sub-packages. Many (like Getopt::Long in this bug) exist only in the core perl rpm. And with the core/vendor directories merged, a separate perl-Getopt-Long rpm will conflict with Getopt::Long from core perl. I guess perl.spec needs a little more work up front to split as much as possible into separate sub-packages. -- Iain. -- 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 Ok, but in this case we need for almost every provides a sub-package. Wouldn't be sufficient to check perl.spec and create sub-package after the separated module will be needed? -- 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
rawhide report: 20100316 changes
Compose started at Tue Mar 16 08:15:09 UTC 2010 Broken deps for i386 -- easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 emotion-0.1.0.042-5.fc12.i686 requires libecore_job.so.0 emotion-0.1.0.042-5.fc12.i686 requires libevas.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_fb.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_x.so.0 emotion-0.1.0.042-5.fc12.i686 requires libecore_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_txt.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_job.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libevas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_fb.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf_evas.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_file.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libefreet_mime.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_imf.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_con.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_ipc.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedbus.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libehal.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_x.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libedje.so.0 enlightenment-0.16.999.050-5.fc12.i686 requires libecore_evas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libedje.so.0 epsilon-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_ipc.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libevas.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_fb.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_file.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_con.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_x.so.0 epsilon-xine-0.3.0.012-9.fc12.i686 requires libecore_evas.so.0 evolution-couchdb-0.3.2-2.fc13.i686 requires libcouchdb-glib-1.0.so.1 ewl-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet.so.0 ewl-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-0.5.2.042-12.fc12.i686 requires libefreet_mime.so.0 ewl-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_txt.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libevas.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_file.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libedje.so.0 ewl-devel-0.5.2.042-12.fc12.i686 requires libecore_evas.so.0 hornsey-1.5.2-0.1.fc13.i686 requires libclutter-gst-0.10.so.0 inkscape-0.47-6.fc13.i686 requires libMagickCore.so.2 inkscape-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagick++.so.2 inkscape-view-0.47-6.fc13.i686 requires libMagickCore.so.2 konq-plugins-4.4.0-2.fc13.i686 requires kdebase4(x86-32) = 0:4.4.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 murmur-1.1.8-15.fc12.i686 requires libIce.so.33 murmur-1.1.8-15.fc12.i686 requires libIceUtil.so.33 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas_hg.so.2 openvas-libnasl-2.0.2-3.fc13.i686 requires libopenvas.so.2 paperbox-0.4.4-2.fc12.i686 requires libtrackerclient.so.0 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickWand.so.2 php-pecl-imagick-2.2.2-4.fc12.i686 requires libMagickCore.so.2 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 q-magick-7.11-6.fc12.i686 requires libMagickCore.so.2 rss-glx-0.9.1.p-2.fc13.i686 requires libMagickCore.so.2 rss-glx-0.9.1.p-2.fc13.i686 requires
Re: Akonadi's unix sockets location
On Tue, Mar 16, 2010 at 12:16 PM, Daniel J Walsh dwa...@redhat.com wrote: PLEASE do not use /tmp for communications. Use /var/run if the service is running as root, or can create a socket in /var/run. In this case I believe it's a per-user service. In which case you don't have much of a choice, because you can't use $HOME or you'll be broken by the sysadmins that inflict NFS on users. The dbus session socket is currently in /tmp, but with a random name, and the session bus rejects connections by processes not matching its own uid. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote: There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ Imho it was not that obvious that there is a bug present, because these kind of delays are usual with RPMFusion, because the repos are not directly synced. E.g. I just expected it to work within some days and if it did not, then I would have thought there might be something wrong. Regards Till pgpm8rpFAFZnz.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Akonadi's unix sockets location
On 03/16/2010 12:29 PM, Colin Walters wrote: On Tue, Mar 16, 2010 at 12:16 PM, Daniel J Walshdwa...@redhat.com wrote: PLEASE do not use /tmp for communications. Use /var/run if the service is running as root, or can create a socket in /var/run. In this case I believe it's a per-user service. In which case you don't have much of a choice, because you can't use $HOME or you'll be broken by the sysadmins that inflict NFS on users. The dbus session socket is currently in /tmp, but with a random name, and the session bus rejects connections by processes not matching its own uid. Ok if they are from the same login session and same UID it is reasonable to expect them to share /tmp. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Bug 568172] virt-top exits sometimes when the window is resized
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568172 Daniel Berrange berra...@redhat.com changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #3 from Daniel Berrange berra...@redhat.com 2010-03-16 13:00:48 EDT --- This was included in last rebase to 0.7.8 tree -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ ocaml-devel mailing list ocaml-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/ocaml-devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Rahul Sundaram wrote: Updates policy won't necessarily help in this case. AutoQA might but then cross repo coordination is at times tricky esp with much less people taking care of administration of third party repos. There's no problem to fix here at all. An updated gstreamer-plugins-bad is already available from RPM Fusion Free updates. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Stable Release Updates types proposal (was Re: Fedora Board Meeting Recap 2010-03-11)
Oscar Bacho wrote: There is one good update of gstreamer with include gstreamer-bad-free. And it has file conflict with gstreamer-bad of rpm-fusion and with gstreamer-good It seem to me that fedora needs a stable update policy. You just need to update gstreamer-plugins-bad from RPM Fusion as well, it's already available in the RPM Fusion updates. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Desktop app maintainers: Please check for StartupNotify=true
Colin Walters wrote: The main tricky situation comes when the app implements single-instance behavior internally, and does some sort of IPC (dbus, whatever) to talk to an existing instance. In GNOME 3 this doesn't matter as much because we do single-instance by default, but otherwise it's definitely possible to get the stale Starting foo... until it times out. Actually handling this correctly is tricky[1], and I just noticed one of my apps doesn't. Maybe I should really take the plunge and backport app tracking to GNOME 2 which would obviate this. Single-instance apps should really use something like libunique or KDE's KUniqueApplication instead of reinventing the wheel. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Fwd: [unladen-swallow] Upgrading to llvm-2.7]
[CCing Fedora Python SIG: context is that unladen-swallow is the optimized branch of python with JIT, and Jeffrey Yasskin is working towards being able to dynamically link Python against LLVM, in the python 3.3 timeframe] Does Fedora's LLVM build have just a single configuration, or would it be easy to support two? (Not sure if it should) ---BeginMessage--- I'm currently writing the patch to upgrade us to llvm-2.7. I plan to commit it as soon as possible after Tanya releases the first pre-release (which, according to http://llvm.org/, should have been 3 days ago). I intend to stop supporting in-tree builds at that point. LLVM's ABI changes depending on whether it's compiled with or without assertions, so you'll probably have to install it twice: +Asserts to build --with-pydebug and -Asserts to build --without-pydebug. I'll try to make configure check that everything matches, but that may come after the initial checkin. You all don't need to do anything now. I'll send another email when I commit. Jeffrey ---End Message--- ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Re: rpms/remmina/F-13 import.log,1.1,1.2 remmina.spec,1.4,1.5
Am Dienstag, den 16.03.2010, 17:36 + schrieb Damien Durand:
Author: splinux
Update of /cvs/pkgs/rpms/remmina/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21694/F-13
Modified Files:
import.log remmina.spec
Log Message:
Damian,
please give a log message and please DO NOT use cvs-import.sh for
package updates, just commit the changes. With cvs-import you have no
option to change the changes.
-Requires: rdesktop, xorg-x11-server-Xephyr
+Requires: rdesktop, xorg-x11-server-Xephyr
-Provides: grdc = %{version}
-Obsoletes: grdc 0.6.1
+Provides: grdc = %{version}
+Obsoletes: grdc 0.6.1
Although this minor, you broke the formatting and made the spec harder
to read.
%description
-Remmina is a remote desktop client written in GTK+, aiming to be useful for
-system administrators and travelers, who need to work with lots of remote
-computers in front of either large monitors or tiny netbooks.
+Remmina is a remote desktop client written in GTK+, aiming to be useful
+for system administrators and travellers, who need to work with lots
+of remote computers in front of either large monitors or tiny netbooks.
-Remmina supports multiple network protocols in an integrated and consistent
-user interface. Currently RDP, VNC, XDMCP and SSH are supported.
+Remmina supports multiple network protocols in an integrated and consistant
+ user interface. Currently RDP, VNC, XDMCP and SSH are supported.
You brought all the typos back that I fixed yesterday! :( Please use
rpmlint to check the spelling.
%changelog
+* Tue Mar 16 2010 Damien Durand spli...@fedoraproject.org - 0.7.4-3
+- Fix changelog
+
* Tue Mar 16 2010 Christoph Wickert cwick...@fedoraproject.org - 0.7.4-2
- Add patch to fix DSO issue
@@ -87,7 +90,7 @@ gtk-update-icon-cache %{_datadir}/icons/
- Upstream release
- Add rdesktop, xorg-x11-server-Xephyr in Requires
- Add grdc in Provides/Obsoletes
-- Add --enable-vnc=dl in %%configure
+- Add enable-vnc=dl in configure
As you see the changelog was already fixed. There was no need fix
anything, I already fixed everything yesterday but you overwrote my
changes again.
Your updates are completely useless. Please DO NOT push them on any
branch.
Regards,
Christoph
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rpms/remmina/F-13 import.log,1.1,1.2 remmina.spec,1.4,1.5
Am Dienstag, den 16.03.2010, 19:08 +0100 schrieb Christoph Wickert: With cvs-import you have no option to change the changes. s/change/check Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using generally useful macros
Nikolay Ulyanitsky wrote: There are a lot of generally useful macros in Fedora, which are not described in the Fedora wiki: %__awk, %__bzip2, %__cat, %__chgrp, %__chmod, %__chown, %__cp, %__cpio, %__file, %__gpg, %__grep, %__gzip, %__id, %__install, %__ln_s, %__lzma, %__xz, %__make, %__mkdir, %__mkdir_p, %__mv, %__patch, %__perl, %__pgp, %__python, %__rm, %__rsh, %__sed, %__ssh, %__tar, %__unzip, etc. They're not described because they're actually not generally useful at all, but completely useless. They just expand to full paths which makes no sense because PATH exists for a reason, and sometimes not even that. These macros are defined in /usr/lib/rpm/macros. Mostly for historical/backwards-compatibility reasons, I guess. It also increases compatibility with specfiles from some other distros which really like those macros for some reason. Some maintainers use them, some do not. What is recommended way? As others have already recommended: Don't use that junk. :-) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: btrfs supported in Fedora 12?
drago01 wrote: You can't ... you need to use another installation method than the live media to use any other fs than ext4. The live media installation basically copies the the ext4 image to disk and re-sizes it. Using the install DVD or a netinstall image you can use any supported fs (including brtfs when passing the magic icantbelieveitsnotbtr). It's also possible to convert the ext4 partition written by the live image to btrfs post installation, btrfs can convert ext* partitions. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: DeviceKit-power has been renamed to upower
Richard Hughes wrote: I'm doing an obsoletes, but I would rather people feel the pain of having to update the spec files now (early in the F14 cycle) rather than when we remove the compatibility provides in over a years time, and when nobody remembers what the new name is. So you just never remove the compatibility Provides? Problem solved. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using generally useful macros
On Tue, Mar 16, 2010 at 07:09:59PM +0100, Kevin Kofler wrote: Nikolay Ulyanitsky wrote: There are a lot of generally useful macros in Fedora, which are not described in the Fedora wiki: %__awk, %__bzip2, %__cat, %__chgrp, %__chmod, %__chown, %__cp, %__cpio, %__file, %__gpg, %__grep, %__gzip, %__id, %__install, %__ln_s, %__lzma, %__xz, %__make, %__mkdir, %__mkdir_p, %__mv, %__patch, %__perl, %__pgp, %__python, ^ %__rm, %__rsh, %__sed, %__ssh, %__tar, %__unzip, etc. They're not described because they're actually not generally useful at all, but completely useless. They just expand to full paths which makes no sense because PATH exists for a reason, and sometimes not even that. These macros are defined in /usr/lib/rpm/macros. Mostly for historical/backwards-compatibility reasons, I guess. It also increases compatibility with specfiles from some other distros which really like those macros for some reason. Some maintainers use them, some do not. What is recommended way? As others have already recommended: Don't use that junk. :-) The python rpmdev-newspec templates use %__python btw. I do not know, whether it is somehow required for the python multiple stack support, though. Regards Till pgp6QtQtbi2lp.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100316 changes
Compose started at Tue Mar 16 09:15:16 UTC 2010 Broken deps for i386 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 easystroke-0.5.2-1.fc13.i686 requires libboost_serialization-mt.so.5 edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- doodle-0.6.7-5.fc12.i686 requires libextractor.so.1 doodle-0.6.7-5.fc12.x86_64 requires libextractor.so.1()(64bit) easystroke-0.5.2-1.fc13.x86_64 requires libboost_serialization-mt.so.5()(64bit) edje-0.9.9.050-6.fc12.i686 requires libembryo.so.0 edje-0.9.9.050-6.fc12.x86_64 requires libembryo.so.0()(64bit) linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 New package GitPython Python Git Library New package cifs-utils Utilities for mounting and managing CIFS mounts New package perl-Color-Calc Simple calculations with RGB colors New package perl-Data-JavaScript Dump perl data structures into JavaScript code New package perl-File-DirCompare Perl module to compare two directories using callbacks Updated Packages: adaptx-0.9.13-9.fc13 * Thu Mar 11 2010 Peter Lemenkov lemen...@gmail.com - 0.9.13-9 - Added missing requires jpackage-utils bullet-2.75-2.fc13 -- * Tue Mar 09 2010 Rex Dieter rdie...@fedoraproject.org - 2.75-2 - pkgconfig file not installed (#549051) eclipse-birt-2.5.2-1.fc13 - * Fri Mar 05 2010 Alexander Kurtakov akurt...@redhat.com 2.5.2-1 - Update to 2.5.2. eclipse-dtp-1.7.2-1.fc13 * Wed Mar 03 2010 Alexander Kurtakov akurt...@redhat.com 1.7.2-1 - Update to 1.7.2. eclipse-mylyn-3.3.2-2.fc13 -- * Wed Mar 03 2010 Alexander Kurtakov akurt...@redhat.com 3.3.2-2 - Relax bundle version requires for commons-lang. * Thu Feb 25 2010 Alexander Kurtakov akurt...@redhat.com 3.3.2-1 - Update to 3.3.2. eclipse-pydev-1.5.5-1.fc13 -- * Fri Mar 05 2010 Alexander Kurtakov akurt...@redhat.com 1:1.5.5-1 - Update to 1.5.5. fife-0.3.0-4.fc13 - * Tue Mar 09 2010 Thomas Kowaliczek linuxdon...@linuxdonald.de - 1:0.3.0-4 - Fixed Bug #564752 - Thanks for the patch Terje git-cola-1.4.1.2-3.fc13 --- * Sat Mar 13 2010 Ben Boeckel maths...@gmail.com - 1.4.1.2-3 - Backport patch for documentation path hunspell-te-0.20050929-5.fc13 - * Mon Mar 08 2010 Parag pnemade AT redhat.com - 0.20050929-5 - Resolves:rh#568227-[te_IN]Fix %description and license tag ibus-pinyin-1.2.99.20100315-1.fc13 -- * Mon Mar 15 2010 Peng Huang shawn.p.hu...@gmail.com - 1.2.99.20100315-1 - Update to 1.2.99.20100315 iok-1.3.10-1.fc13 - * Mon Mar 08 2010 Parag Nemade panemade AT gmail.com- 1.3.10-1 - Update to Next release 1.3.10 libguestfs-1.0.85-2.fc13.4 -- * Fri Mar 12 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.85-2.4 - Backport upstream patch to remove dependency on /lib/libntfs-3g.so.N. - The above depends on the bash quoting patch, so apply that first. * Mon Mar 08 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.85-2.3 - Rebuild against latest plymouth in F-13 updates-testing. * Mon Mar 08 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.85-2.2 - Bump and rebuild. * Fri Mar 05 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.85-2.1 - Bump and rebuild. * Wed Mar 03 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.85-2 - Bump and rebuild. * Mon Mar 01 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.85-1 - New upstream version 1.0.85. - Remove hivex, now a separate upstream project and package. - Remove supermin quoting patch, now upstream. * Mon Mar 01 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.84-6 - Fix quoting in supermin-split script (RHBZ#566511). - Don't include bogus './builddir' entries in supermin hostfiles (RHBZ#566512). * Mon Feb 22 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.84-4 - Don't include generator.ml in rpm. It's 400K and almost no one will need it. - Add comments to spec file about how repo building works. - Whitespace changes in the spec file. * Mon Feb 22 2010 Richard W.M. Jones rjo...@redhat.com - 1:1.0.84-3 - Bump and rebuild. madan-fonts-2.000-1.fc13 * Tue Feb 23 2010 Parag pnemade AT redhat.com - 2.000-1 - Update to next upstream release - Resolves: rh#335851-[ne_NP] Add license text file to madan-fonts package - Resolves: rh#520047-[ne_NP] Need fontconfig rules for Madan font mingw32-qt-4.6.2-1.fc13
Re: Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
Jesse Keating wrote: On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote: #355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path Does this one really have to wait for a meeting? It's a pretty straight forward case, deps are broken, it couldn't have been installed anywhere to begin with. The question is whether to allow doing the untagging without an Epoch bump, making F-13 go backwards. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Using generally useful macros
On 03/16/2010 02:32 PM, Till Maas wrote: On Tue, Mar 16, 2010 at 07:09:59PM +0100, Kevin Kofler wrote: Nikolay Ulyanitsky wrote: There are a lot of generally useful macros in Fedora, which are not described in the Fedora wiki: %__awk, %__bzip2, %__cat, %__chgrp, %__chmod, %__chown, %__cp, %__cpio, %__file, %__gpg, %__grep, %__gzip, %__id, %__install, %__ln_s, %__lzma, %__xz, %__make, %__mkdir, %__mkdir_p, %__mv, %__patch, %__perl, %__pgp, %__python, ^ %__rm, %__rsh, %__sed, %__ssh, %__tar, %__unzip, etc. They're not described because they're actually not generally useful at all, but completely useless. They just expand to full paths which makes no sense because PATH exists for a reason, and sometimes not even that. These macros are defined in /usr/lib/rpm/macros. Mostly for historical/backwards-compatibility reasons, I guess. It also increases compatibility with specfiles from some other distros which really like those macros for some reason. Some maintainers use them, some do not. What is recommended way? As others have already recommended: Don't use that junk. :-) The python rpmdev-newspec templates use %__python btw. I do not know, whether it is somehow required for the python multiple stack support, though. I'm pretty sure the point of these was to support other /operating systems/, where e.g. you might need sed from /usr/lib/ucb . That's total hogwash, of course, and these are actually completely useless. -- Peter Obviously, a major malfunction has occurred. -- Steve Nesbitt, voice of Mission Control, January 28, 1986 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What is the official way to download scratch builds from Koji?
I recently discovered this script for downloading scratch builds from Koji: http://people.redhat.com/mikeb/scripts/download-scratch.py Is this the official way of doing this? If so, is this packaged somewhere? (e.g. in a more recent build of koji or rpmdevtools). I keep losing the URL, and never have this script to hand. (I'd also really like a rpmlint-scratch TASK_ID command, packaged somewhere, as I do this regularly during the developer side of a package review) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On 16.03.2010 17:42, Till Maas wrote: On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote: There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ Imho it was not that obvious that there is a bug present, because these kind of delays are usual with RPMFusion, because the repos are not directly synced. That IMHO something that needs fixing on the Fedora side (e.g. in yum) http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html But I lost energy driving a solution forward. E.g. I just expected it to work within some days and if it did not, then I would have thought there might be something wrong. Well, there were a few cases in the past where problems like this one persisted for a few days because everybody thought like you outline :-/ But I have no solution for that apart from if in a doubt file a bug :-( CU knurd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gdbm soname change in Rawhide, package rebuild needed
Jesse Keating (jkeat...@redhat.com) said: However, it makes no sense to use compat-gdbm for a long time, as the API is the same, and no source code changes are needed in packages using gdbm-1.8.0 to use gdbm-1.8.3. I don't see much problem with removing compat-gdbm once all our dependent packages are rebuilt. My concern would be if gdbm is a widely-enough used ABI that we'd want to keep it like we keep compat-db or compat-openssl. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's (2010-03-16) FESCo meeting (note new DST meeting time)
On Tue, 2010-03-16 at 19:45 +0100, Kevin Kofler wrote: Jesse Keating wrote: On Mon, 2010-03-15 at 14:14 -0600, Kevin Fenzi wrote: #355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path Does this one really have to wait for a meeting? It's a pretty straight forward case, deps are broken, it couldn't have been installed anywhere to begin with. The question is whether to allow doing the untagging without an Epoch bump, making F-13 go backwards. Kevin Kofler I had misunderstood the problem. I assumed when the maintainer told me that the deps were broken and nobody could install it, that he meant nobody could install it, not that it is unlikely that anybody would install it. Going backwards only really matters if the package happens to get into people's systems, that's what we're trying to protect against. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
vendor vs core?
One thing we didn't talk about here -- given that the independent subpackages are replacing dual-lifed core modules, should we be using %perl_archlib/_privlib rather than %perl_vendorarch/_vendorlib? I realise this is mainly nomenclature here, as we currently have one set to the other, but it would seem to make sense (especially if we go back to having distinct vendor directories). I have a preference to using the core macros vs vendor macros, but am ok with it either way as long as we realize that we're making a choice here. -Chris -- Chris Weyl Ex astris, scientia -- 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 568984] Build perl-Authen-PAM for EPEL-5
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568984 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-03-16 15:33:32 EDT --- perl-Authen-PAM-0.16-8.el4 has been pushed to the Fedora EPEL 4 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Authen-PAM'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Authen-PAM-0.16-8.el4 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 569300] Release perl-Hash-Merge for EPEL
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=569300 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-03-16 15:33:37 EDT --- perl-Hash-Merge-0.11-2.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Hash-Merge'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Hash-Merge-0.11-2.el5 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 568984] Build perl-Authen-PAM for EPEL-5
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=568984 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|ASSIGNED|ON_QA --- Comment #4 from Fedora Update System upda...@fedoraproject.org 2010-03-16 15:32:55 EDT --- perl-Authen-PAM-0.16-8.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Authen-PAM'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Authen-PAM-0.16-8.el5 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 569300] Release perl-Hash-Merge for EPEL
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=569300 --- Comment #5 from Fedora Update System upda...@fedoraproject.org 2010-03-16 15:35:16 EDT --- perl-Hash-Merge-0.11-2.el4 has been pushed to the Fedora EPEL 4 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Hash-Merge'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/perl-Hash-Merge-0.11-2.el4 -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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 561389] amavisd-new always reports Shutting down amavisd: Daemon [19248] terminated by SIGTERM
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=561389 --- Comment #3 from John Griffiths fedor...@grifent.com 2010-03-16 15:40:15 EDT --- Patch worked. Hope this gets into the build package. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. -- 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: Conflicts in latest update
On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote: On 16.03.2010 17:42, Till Maas wrote: On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote: There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ Imho it was not that obvious that there is a bug present, because these kind of delays are usual with RPMFusion, because the repos are not directly synced. That IMHO something that needs fixing on the Fedora side (e.g. in yum) http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html But I lost energy driving a solution forward. I'm not sure what you want us to do, the main problem is that splitting a DB of packages and then stitching it back together doesn't work 100% of the time ... this isn't us being stupid: http://en.wikipedia.org/wiki/CAP_Theorem ...yum repo DBs are AP and not C. Skip-broken helps in all cases apart from file conflicts, which is a packaging bug. Your idea of timed skip-broken by default doesn't work because we don't have a date package was released ... although PK currently does skip-broken by default, all the time. E.g. I just expected it to work within some days and if it did not, then I would have thought there might be something wrong. Well, there were a few cases in the past where problems like this one persisted for a few days because everybody thought like you outline :-/ But I have no solution for that apart from if in a doubt file a bug :-( Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't think we can legally do the same ... but I'm not sure). Finding the file conflicts automatically is harder (you need to download all the rpms), and it's not fast, but it's possible (Seth has a script, IIRC). -- James Antill - ja...@fedoraproject.org http://yum.baseurl.org/wiki/releases http://yum.baseurl.org/wiki/whatsnew/3.2.27 http://yum.baseurl.org/wiki/YumMultipleMachineCaching -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, 16 Mar 2010, James Antill wrote: Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't think we can legally do the same ... but I'm not sure). Finding the file conflicts automatically is harder (you need to download all the rpms), and it's not fast, but it's possible (Seth has a script, IIRC). The script does this: 1. look up any potential conflicts in the filelists metadata 2. download the headers from those pkgs and see if the conflicts are real or fake conflicts (ie: multilib-allowed) it's not fast - it has to traverse a lot of data, of course. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On 16.03.2010 20:46, James Antill wrote: On Tue, 2010-03-16 at 20:09 +0100, Thorsten Leemhuis wrote: On 16.03.2010 17:42, Till Maas wrote: On Tue, Mar 16, 2010 at 01:45:33PM +0100, Thorsten Leemhuis wrote: There are so many developers around on this list that know: reporting bugs is the right way to get problems fixed and fixing things is way better than posting workarounds to public places for various reasons -- nevertheless nobody filed a bug yet afaics :-/ Imho it was not that obvious that there is a bug present, because these kind of delays are usual with RPMFusion, because the repos are not directly synced. That IMHO something that needs fixing on the Fedora side (e.g. in yum) http://www.redhat.com/archives/fedora-devel-list/2008-August/msg00041.html But I lost energy driving a solution forward. I'm not sure what you want us to do, Actually I'm not sure myself what to do and haven't put much thought into it lately... the main problem is that splitting a DB of packages and then stitching it back together doesn't work 100% of the time ... this isn't us being stupid: http://en.wikipedia.org/wiki/CAP_Theorem ...yum repo DBs are AP and not C. Well, the big hammer solution to make it work 100% of the time then would be: RPM Fusion should disable the Fedora repos and provide the matching repodata for Fedora itself. But that solution would be over designed, complicated and inflexible, so don't take that suggestion seriously ;-) But I don't think 100% of the time is needed, but maybe it could be made a lot whole lot better with some fine tuning. The simple solution that would fix most of the problems afaics: an additional config value flag in (say) rpmfusion-free-updates.repo that expresses if repo fedora-updates gets updated repodata then check for updated rpmfusion-free-repodata not only on the mirrors of this configured repo, but also on server download1.rpmfusion.org (master repo for RPM Fusion). Then everything should just work for people as long as RPM Fusion pushed matching updates in parallel. Note that the stuff needs to work vice versa as -- e.g. if yum sees updated repo data for RPM Fusion then check for new fedora-updates repodata as well. Skip-broken helps in all cases apart from file conflicts, which is a packaging bug. Or a mirror lag and cache problems, like it would have happened with gst-plugins-bad if we had pushed it at the right time, as in some cases a freshly updated fedora-updates repo will get combined with a outdated rpmfusion updates repo from a not-yet-updated mirror (or vice versa). Your idea of timed skip-broken by default doesn't work That was just me thinking out loud ;-) and it's not my preferred solution for the problem at hand these days... because we don't have a date package was released ... And would that be needed at all? The timer could simply start locally then yum sees the problem seen for the first time. But as I said: Not sure if that worth investigating, but it might, as yum bailing out when a problem happens seems to confuse quite a lot of people (a colleague of mine for example always gets annoyed by that and asks for help). Sure, those that don't know how to deal with it might better be using PK, but we can't force them to do that and those problems make us look bad :-/ Anyway: the timed skip-broken by default has a big downside in any case: you might lose features temporary. Let's assume new gstreamer packages where a plugin was moved from -bad to -good. Let's further assume Fedora and RPM Fusion would have shipped the new matching and updated packages in parallel. Then yum on some systems will install the new -bad package from rpmfusion (which lacks the plugin now) but not the new -good package from Fedora, if the mirror yum chose was not updated yet (or updated a few hours earlied and was not checked for updated repodata due to caching). Than the user temporary looses a feature -- bad :-/ E.g. I just expected it to work within some days and if it did not, then I would have thought there might be something wrong. Well, there were a few cases in the past where problems like this one persisted for a few days because everybody thought like you outline :-/ But I have no solution for that apart from if in a doubt file a bug :-( Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't think we can legally do the same ... but I'm not sure). Finding the file conflicts automatically is harder (you need to download all the rpms), and it's not fast, but it's possible (Seth has a script, IIRC). Yeah, sure, that's right, but there were other information that made be write the above: RPM Fusion has just a few contributors and so little man-power, it didn't even manage to get the repo closure scripts running on their own hosts regularly -- there were some attempts over the years, but nothing came out of it :-/ I fear that the lack of man power and contributors will result in RPM Fusion falling apart sooner
Re: Conflicts in latest update
On Tue, 16 Mar 2010, Jesse Keating wrote: On Tue, 2010-03-16 at 15:46 -0400, James Antill wrote: but it's possible (Seth has a script, IIRC). I do believe seth's script works purely from metadata without downloading the rpms. it gets the headers from the pkgs w/o downloading the whole package. the magic of byte-ranges -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
What is the future of logwatch?
Hey List, In the org that i work for, we use logwatch for log monitoring. Since puppet is too new to have a module in logwatch, i've had the 'joy' recently of attempting to write a functional module. In doing so, i have a number of issues i would like to bring up about logwatch in Fedora (and RHEL/CentOS). To begin with, like a good netizen, i sent a message to the mailing list upstream. So far i've heard no reply. There's the chance that it got caught in my spam filter, but i've gotten one message from the ML already. It feels like upstream is dead. There has also been no release since 2007. Since it still 'just works' i won't bring out the fire and brimstone and demand it be removed, but i would like to know, how are we going to support this? This question is important in the context of the issues i had programming for logwatch. A well programmed tool maintains orthogonal features in an orthogonal way. I ran into some serious bugs while trying to develop a robust module. Logwatch has two modes, one for a machine with a single set of logs, and one for generating reports for a machine with multiple logs, namely your centralised logging box. The snippets of code that filter the logs you want to analyse allow you to control for the date range and the machine the logged event was generated on. When trying to code for the puppet logs, my code ultimately only worked on the single nodes, but crapped out on our logging box. After debugging the issue, it's obvious that it's doing some prefiltering per host that is occluding all the puppet logs, when the 'splithosts' feature is enabled. Extending and maintaining this package is going to be difficult without a willing maintainer. If this is just something that needs a bug report, i would appreciate if the package maintainer, according to zodbot Karel Klíč, could speak up on this. If no one is willing to maintain logwatch, i would like to ask why is it enabled by default? For most environments, logwatch is ignored/disabled in lieu of other solutions. People who use logwatch seriously are already aware of its presence and will enable it when disabled. They are also generaly experts, and from my experience been around the sysadmin block quite a few times. For the non-expert user, discussions of target audience aside, either they know about logwatch, and perhaps keep an eye on it, or will never find it. I refer to the fact that the only way to know about logwatch on a running system is that innocous you've got mail in /var/spool/mail/root' message. Then you have to know to open up your mbox, which in my case means installing mutt which is not installed by default, and read it, and then know it's logwatch, and realize what it's there for. There are 'expert tips' i've seen that remind newbs to check logwatch on their own machines, but if this is something important, it should be more obvious, and if it's not so important, why is it enabled by default? I'm not going to bike shed, so i'm not going to ask for any particular action. We don't have the time in our organisation to take up maintenance of logwatch, so we clearly are going to look for another solution. Still, i would like to ask the persons who made the decision to enable this by default, is it still relevant? Or is it something that's in danger of becoming cruft? Am i missing a certain perspective on why it's enabled by default? -Yaakov DISCLAIMER: I will not entertain bike shedding on this thread. It sounds so simple that everyone could imagine having one's own opinion on it. If you waste everyone's time with a 'me too', or anything that tries to convert a mailing list discussion into a survey, i will be unhappy. And you know don't want to find out what that means. For every message sent to a ML, it requires a person 10 seconds approximately to read and/or ignore it. Considering the number of people subscribed here, you will waste a considerable number of man hours with a useless reply, so before you hit send, take 10 seconds to decide if you want to reply. Please. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Upstream revamp of byte-compilation
On Tue, Mar 16, 2010 at 11:14:17AM -0400, David Malcolm wrote: IIRC, we currently jump through some hoops in brp-python-bytecompile; upstream landed some new ways of doing this in this patch for 2.7/3.2: http://bugs.python.org/issue8140 (Not sure if it's helpful as I think Toshio solved this already in F13's rpm-build, but I wanted to at least send it to the SIG in case it's of interest) I hate touching working code ;-) so I think I'll pass on changing brp-python-bytecompile at this time. But those extra options could be helpful if we have to revamp this in the future. -Toshio pgpcILk3Hdn4p.pgp Description: PGP signature ___ python-devel mailing list python-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
Storage Test Day Thursday 2010-03-18
There's always more testing to do, and this week is no exception: it's Test Day time again! This Thursday, 2010-03-18, is storage Test Day [1]. Fedora 13 features several improvements to disk management [2], and this Thursday is our time to test them out! Anyone with a computer and a hard disk can do some of the testing, or if you have a more exotic configuration - many disks, RAID arrays, LVM setups, multichannel, SCSI or fibre channel configurations, anything like that - we'd love to get your results. Most of the testing can be done from a live environment, and live images are available for testing. As always, test cases with clear step-by-step testing instructions will be available on the Test Day page, so testing is easy! The Test Day runs all Thursday in #fedora-test-day on Freenode IRC. [1] https://fedoraproject.org/wiki/Test_Day:2010-03-18_Palimpsest [2] https://fedoraproject.org/wiki/Features/UdisksImprovements -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems in packaging kicad
On 03/16/2010 08:27 AM, Alain Portal wrote:
Hi,
I get some problem in packaging kicad.
Linking fails, and I don't know how to solve.
There is no problem if I compile without packaging.
Well, I doubt that seriously. This code is a bit of a mess (but still
not as painful as chromium).
Attached is a new spec file, and two patches that fix the problems which
were preventing it from building.
~spot, who feels dirty after spending so much time hacking around cmake
diff -up kicad-2010.03.14/eeschema/CMakeLists.txt.kbool
kicad-2010.03.14/eeschema/CMakeLists.txt
--- kicad-2010.03.14/eeschema/CMakeLists.txt.kbool 2010-03-15
08:24:32.0 -0400
+++ kicad-2010.03.14/eeschema/CMakeLists.txt2010-03-16 13:21:28.364443236
-0400
@@ -154,7 +154,7 @@ if(APPLE)
set_target_properties(eeschema PROPERTIES MACOSX_BUNDLE_INFO_PLIST
${CMAKE_CURRENT_SOURCE_DIR}/Info.plist)
endif(APPLE)
-target_link_libraries(eeschema common bitmaps polygon ${wxWidgets_LIBRARIES}
${GDI_PLUS_LIBRARIES})
+target_link_libraries(eeschema common bitmaps kbool polygon
${wxWidgets_LIBRARIES} ${GDI_PLUS_LIBRARIES})
install(TARGETS eeschema
DESTINATION ${KICAD_BIN}
diff -up kicad-2010.03.14/kicad/CMakeLists.txt.kbool
kicad-2010.03.14/kicad/CMakeLists.txt
--- kicad-2010.03.14/kicad/CMakeLists.txt.kbool 2010-03-10 11:23:50.0
-0500
+++ kicad-2010.03.14/kicad/CMakeLists.txt 2010-03-16 13:21:28.364443236
-0400
@@ -49,7 +49,7 @@ install(TARGETS KiCad
DESTINATION ${KICAD_BIN}
COMPONENT binary)
else(APPLE)
- target_link_libraries(kicad common bitmaps polygon
${wxWidgets_LIBRARIES} ${GDI_PLUS_LIBRARIES})
+ target_link_libraries(kicad common bitmaps kbool polygon
${wxWidgets_LIBRARIES} ${GDI_PLUS_LIBRARIES})
install(TARGETS kicad
DESTINATION ${KICAD_BIN}
COMPONENT binary)
diff -up kicad-2010.03.14/common/CMakeLists.txt.BAD
kicad-2010.03.14/common/CMakeLists.txt
--- kicad-2010.03.14/common/CMakeLists.txt.BAD 2010-03-16 15:07:29.328317975
-0400
+++ kicad-2010.03.14/common/CMakeLists.txt 2010-03-16 15:07:49.162441795
-0400
@@ -44,6 +44,7 @@ set(COMMON_SRCS
hotkeys_basic.cpp
msgpanel.cpp
newstroke_font.cpp
+../pcbnew/class_drc_item.cpp
projet_config.cpp
# pyhandler.cpp
richio.cpp
diff -up kicad-2010.03.14/pcbnew/class_drc_item.cpp.BAD
kicad-2010.03.14/pcbnew/class_drc_item.cpp
diff -up kicad-2010.03.14/demos/CMakeLists.txt.BAD
kicad-2010.03.14/demos/CMakeLists.txt
--- kicad-2010.03.14/demos/CMakeLists.txt.BAD 2010-03-16 15:20:23.281442395
-0400
+++ kicad-2010.03.14/demos/CMakeLists.txt 2010-03-16 15:20:33.465442317
-0400
@@ -1,5 +1,5 @@
install(DIRECTORY ecc83 electric flat_hierarchy interf_u microwave
- pic_programmer pspice sonde xilinx test_xil_95108 video
+ pic_programmer pspice sonde_xilinx test_xil_95108 video
DESTINATION ${KICAD_DEMOS}
COMPONENT resources
PATTERN .svn EXCLUDE)
Name: kicad
Version:2010.03.14
Release:2.rev2462%{?dist}
Summary:Electronic schematic diagrams and printed circuit board artwork
Summary(fr):Saisie de schéma électronique et tracé de circuit imprimé
Group: Applications/Engineering
License:GPLv2+
# URL:http://www.lis.inpg.fr/realise_au_lis/kicad/
URL:http://kicad.sourceforge.net
# Source files created from upstream's SVN repository
Source: kicad-%{version}.tar.bz2
#Source1:kicad-doc-%{version}.tar.bz2
#Source2:kicad-library-%{version}.tar.bz2
Source3:kicad-ld.conf
Patch0: kicad-2010.03.14-link-fixes.patch
# Fix spacing issue
Patch1: kicad-2010.03.14-fix-demos-install.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: desktop-file-utils
BuildRequires: wxGTK-devel
BuildRequires: boost-devel
BuildRequires: cmake
Requires: electronics-menu
%description
Kicad is an EDA software to design electronic schematic
diagrams and printed circuit board artwork up to 16 layers.
Kicad is a set of four softwares and a project manager:
- Eeschema: schematic entry
- Pcbnew: board editor
- Gerbview: GERBER viewer (photoplotter documents)
- Cvpcb: footprint selector for components used in the circuit design
- Kicad: project manager
%description -l fr
Kicad est un logiciel open source (GPL) pour la création de schémas
électroniques et le tracé de circuits imprimés jusqu'à 16 couches.
Kicad est un ensemble de quatres logiciels et un gestionnaire de projet :
- Eeschema : saisie de schémas
- Pcbnew : éditeur de circuits imprimés
- Gerbview : visualisateur GERBER (documents pour phototraçage)
- Cvpcb : sélecteur d'empreintes pour les composants utilisés dans le circuit
- Kicad : gestionnaire de projet.
%packagedoc
Summary:Documentations for kicad
Summary(fr):Documentations pour kicad en anglais
Group:
[389-devel] Please review: Bug 521108 - Customer is unable to add a new Role within RHDS 8.1.0
Hi, Please review the patch for this bug: https://bugzilla.redhat.com/show_bug.cgi?id=521108 Patch: https://bugzilla.redhat.com/attachment.cgi?id=400577action=edit https://bugzilla.redhat.com/attachment.cgi?id=400577action=diff Fix description: The console uses resource editor extensions which are registered under cn=ResourceEditorExtension, ou=1.1, ou=admin, ou=Global Preferences, ou=example.com, o=NetscapeRoot in the admin server. Some extensions are provided by idm-console-framework, but some others are provided by 389-ds-console. Currently the console will load all extensions during console initialization. However, when a user uses the console for the first time it doesn't have the 389-ds-console jar file yet. The jar file will only be downloaded when the user clicks the server node, but at that point the console will not try to load the extensions again. This problem can be reproduced by removing ~/.389-console/jars folder and then restarting the console. The patch will change the behaviour such that during initialization the console will only load the extensions from idm-console-framework (without @ sign). When the user clicks the server node it will load the extensions from the 389-ds-console jar file (ending with @ + jar file name). Thanks. -- Endi S. Dewata -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Conflicts in latest update
On Tue, 16 Mar 2010 15:46:16 -0400, James wrote: Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't think we can legally do the same ... but I'm not sure). Finding the file conflicts automatically is harder (you need to download all the rpms), and it's not fast, but it's possible (Seth has a script, IIRC). I've created and published a proof-of-concept script a couple of times before. It's the one I've used to file all those bugs about conflicts in Rawhide. http://mschwendt.fedorapeople.org/confcheck-remote-split2.py (that's a more experimental version that tries to work with just 1GB of RAM) It does not download all packages, but just the headers. For packages stored in a local mirror, the speed isn't too bad. It ran approx. 11 minutes with remote Rawhide, though, on an average dual core machine. Will Woods/autoqa features a conflicts checker, too, https://fedorahosted.org/pipermail/autoqa-results/2010-March/date.html which is why I haven't continued with filing further tickets or with enhancing my script. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Conflicts in latest update
On Tue, 2010-03-16 at 21:46 +0100, Michael Schwendt wrote: On Tue, 16 Mar 2010 15:46:16 -0400, James wrote: Rpmfusion can run auto QA like tests on rpmfusion and Fedora (I don't think we can legally do the same ... but I'm not sure). Finding the file conflicts automatically is harder (you need to download all the rpms), and it's not fast, but it's possible (Seth has a script, IIRC). I've created and published a proof-of-concept script a couple of times before. It's the one I've used to file all those bugs about conflicts in Rawhide. http://mschwendt.fedorapeople.org/confcheck-remote-split2.py (that's a more experimental version that tries to work with just 1GB of RAM) It does not download all packages, but just the headers. For packages stored in a local mirror, the speed isn't too bad. It ran approx. 11 minutes with remote Rawhide, though, on an average dual core machine. Will Woods/autoqa features a conflicts checker, too, https://fedorahosted.org/pipermail/autoqa-results/2010-March/date.html which is why I haven't continued with filing further tickets or with enhancing my script. hi, Is there a wiki page with more info on this script please? How it's to be used etc.? -- regards, Ankur - FAS : ankursinha ; franciscod @ Freenode - gpg --keyserver pgp.mit.edu --recv-keys 5E9BF638 signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problems in packaging kicad
Tom spot Callaway wrote: - link fixes. Really, these libraries should be linked properly so they don't need the executable linking calls to be explicitly correct, but cmake gives me a headache. You can use target_link_libraries on a shared library just as well as on an executable. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-App-cpanminus/devel perl-App-cpanminus.spec,1.1,1.2
Author: mmaslano
Update of /cvs/pkgs/rpms/perl-App-cpanminus/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv29378
Modified Files:
perl-App-cpanminus.spec
Log Message:
Add missing BR.
Index: perl-App-cpanminus.spec
===
RCS file: /cvs/pkgs/rpms/perl-App-cpanminus/devel/perl-App-cpanminus.spec,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- perl-App-cpanminus.spec 16 Mar 2010 07:57:55 - 1.1
+++ perl-App-cpanminus.spec 16 Mar 2010 08:03:36 - 1.2
@@ -11,6 +11,7 @@ BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(LWP)
BuildRequires: perl(Module::Build)
+BuildRequires: perl(Test::More)
Requires: perl(LWP)
Requires: perl(Module::Build)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
--
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
first reviews for dual packages
Hello, I've decided fix my build failure of IO::Compress::* (#555420) by updating to the latest version, which passed on my testing F-13. Please someone take a look at reviews: #573928, #573929, #573932 (We can trade reviews if anyone wants some). Best regards, -- Marcela Mašláňová BaseOS team Brno -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: first reviews for dual packages
On 16/03/10 16:33, Iain Arnell wrote: On Tue, Mar 16, 2010 at 5:17 PM, Marcela Maslanovammasl...@redhat.com wrote: - Iain Arnelliarn...@gmail.com wrote: I guess perl.spec needs a little more work up front to split as much as possible into separate sub-packages. Ok, but in this case we need for almost every provides a sub-package. Wouldn't be sufficient to check perl.spec and create sub-package after the separated module will be needed? That would also work, of course. But should be mentioned in the guidelines too. Wouldn't this approach mean that the main perl package needed to be updated whenever a new updated module was needed, which was one of the things this scheme was trying to avoid? Paul. -- 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
rpms/perl-Hash-Merge/devel .cvsignore, 1.2, 1.3 perl-Hash-Merge.spec, 1.3, 1.4 sources, 1.2, 1.3
Author: cweyl
Update of /cvs/extras/rpms/perl-Hash-Merge/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25608
Modified Files:
.cvsignore perl-Hash-Merge.spec sources
Log Message:
* Wed Mar 17 2010 Chris Weyl cw...@alumni.drew.edu - 0.12-1
- PERL_INSTALL_ROOT = DESTDIR, add perl_default_filter
- auto-update to 0.12 (by cpan-spec-update 0.01) (for DBIx::Class)
- added a new br on perl(ExtUtils::MakeMaker) (version 0)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Hash-Merge/devel/.cvsignore,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- .cvsignore 1 Jul 2009 13:59:28 - 1.2
+++ .cvsignore 17 Mar 2010 01:08:39 - 1.3
@@ -1 +1 @@
-Hash-Merge-0.11.tar.gz
+Hash-Merge-0.12.tar.gz
Index: perl-Hash-Merge.spec
===
RCS file: /cvs/extras/rpms/perl-Hash-Merge/devel/perl-Hash-Merge.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-Hash-Merge.spec7 Dec 2009 17:05:10 - 1.3
+++ perl-Hash-Merge.spec17 Mar 2010 01:08:39 - 1.4
@@ -1,6 +1,6 @@
Name: perl-Hash-Merge
-Version:0.11
-Release:4%{?dist}
+Version:0.12
+Release:1%{?dist}
Summary:Merges arbitrary deep hashes into a single hash
Group: Development/Libraries
License:GPL+ or Artistic
@@ -9,9 +9,11 @@ Source0:http://search.cpan.org/C
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
-BuildRequires: perl(Test::More), perl(Clone)
+BuildRequires: perl(Test::More), perl(Clone), perl(ExtUtils::MakeMaker)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
+%{?perl_default_filter}
+
%description
%{summary}.
@@ -24,7 +26,7 @@ make %{?_smp_mflags}
%install
rm -rf %{buildroot}
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -x %{buildroot}%{perl_vendorlib}/Hash/Merge.pm
@@ -44,6 +46,11 @@ rm -rf %{buildroot}
%changelog
+* Wed Mar 17 2010 Chris Weyl cw...@alumni.drew.edu - 0.12-1
+- PERL_INSTALL_ROOT = DESTDIR, add perl_default_filter
+- auto-update to 0.12 (by cpan-spec-update 0.01) (for DBIx::Class)
+- added a new br on perl(ExtUtils::MakeMaker) (version 0)
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.11-4
- rebuild against perl 5.10.1
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Hash-Merge/devel/sources,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -p -r1.2 -r1.3
--- sources 1 Jul 2009 13:59:28 - 1.2
+++ sources 17 Mar 2010 01:08:39 - 1.3
@@ -1 +1 @@
-280b520399a382ac70dfb64442402f85 Hash-Merge-0.11.tar.gz
+875e2d9101bde2f6b410dd12f7e10964 Hash-Merge-0.12.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
File Hash-Merge-0.12.tar.gz uploaded to lookaside cache by cweyl
A file has been added to the lookaside cache for perl-Hash-Merge: 875e2d9101bde2f6b410dd12f7e10964 Hash-Merge-0.12.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
rpms/perl-DBIx-Class/devel find_optional_deps, 1.1, 1.2 perl-DBIx-Class.spec, 1.23, 1.24 sources, 1.9, 1.10
Author: cweyl
Update of /cvs/extras/rpms/perl-DBIx-Class/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv25826
Modified Files:
find_optional_deps perl-DBIx-Class.spec sources
Log Message:
* Sat Mar 06 2010 Chris Weyl cw...@alumni.drew.edu 0.08120-1
- update by Fedora::App::MaintainerTools 0.004
- updating to latest GA CPAN version (0.08120)
- added a new br on perl(Context::Preserve) (version 0.01)
- added manual BR on perl(Test::Moose)
- added a new req on perl(Context::Preserve) (version 0.01)
- dropped old requires on perl(List::Util)
- dropped old requires on perl(Scalar::Util)
- dropped old requires on perl(Storable)
- additional deps script run; 27 deps found
Index: find_optional_deps
===
RCS file: /cvs/extras/rpms/perl-DBIx-Class/devel/find_optional_deps,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- find_optional_deps 4 Mar 2010 08:00:09 - 1.1
+++ find_optional_deps 17 Mar 2010 01:09:33 - 1.2
@@ -15,13 +15,15 @@ use lib $ARGV[0]/lib;
use DBIx::Class::Optional::Dependencies;
# for use starting with DBIC 0.08120
-#my %reqs =
-#%{ DBIx::Class::Optional::Dependencies::_all_optional_requirements() };
-#
+my %reqs =
+%{ DBIx::Class::Optional::Dependencies::_all_optional_requirements() };
+
# output our found deps :)
-#say '# from DBIx::Class::Optional::Dependencies';
-#say BuildRequires: perl($_) . ($reqs{$_} ? = $reqs{$_} : q{})
-#for sort keys %reqs;
+say '# from DBIx::Class::Optional::Dependencies';
+say BuildRequires: perl($_) . ($reqs{$_} ? = $reqs{$_} : q{})
+for sort keys %reqs;
+
+exit;
my @groups = qw{ core cdbicompat deploy admin replicated };
Index: perl-DBIx-Class.spec
===
RCS file: /cvs/extras/rpms/perl-DBIx-Class/devel/perl-DBIx-Class.spec,v
retrieving revision 1.23
retrieving revision 1.24
diff -u -p -r1.23 -r1.24
--- perl-DBIx-Class.spec5 Mar 2010 18:04:28 - 1.23
+++ perl-DBIx-Class.spec17 Mar 2010 01:09:33 - 1.24
@@ -1,7 +1,7 @@
Name: perl-DBIx-Class
Summary:Extensible and flexible object - relational mapper
-Version:0.08119
-Release:3%{?dist}
+Version:0.08120
+Release:1%{?dist}
License:GPL+ or Artistic
Group: Development/Libraries
Source0:
http://search.cpan.org/CPAN/authors/id/R/RI/RIBASUSHI/DBIx-Class-%{version}.tar.gz
@@ -19,6 +19,7 @@ BuildRequires: perl(Class::Inspector)
BuildRequires: perl(Class::MOP) = 0.63
BuildRequires: perl(Class::Trigger)
BuildRequires: perl(Clone)
+BuildRequires: perl(Context::Preserve) = 0.01
BuildRequires: perl(CPAN)
BuildRequires: perl(Data::Dumper::Concise) = 1.000
BuildRequires: perl(Data::Page) = 2.00
@@ -30,24 +31,21 @@ BuildRequires: perl(DBI) = 1.609
BuildRequires: perl(DBIx::ContextualFetch)
BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
BuildRequires: perl(File::Temp) = 0.22
-BuildRequires: perl(List::Util) = 1.19
BuildRequires: perl(Module::Find) = 0.06
-BuildRequires: perl(Moose) = 0.54
+BuildRequires: perl(Moose) = 0.98
BuildRequires: perl(Moose::Util::TypeConstraints) = 0.54
BuildRequires: perl(MooseX::AttributeHelpers) = 0.12
BuildRequires: perl(MRO::Compat) = 0.09
BuildRequires: perl(Path::Class) = 0.18
-BuildRequires: perl(Scalar::Util)
BuildRequires: perl(Scope::Guard) = 0.03
BuildRequires: perl(SQL::Abstract) = 1.61
BuildRequires: perl(SQL::Abstract::Limit) = 0.13
-BuildRequires: perl(SQL::Translator)
-BuildRequires: perl(Storable)
+BuildRequires: perl(SQL::Translator) = 0.11002
BuildRequires: perl(Sub::Name) = 0.04
BuildRequires: perl(Test::Builder) = 0.33
-BuildRequires: perl(Test::Deep)
BuildRequires: perl(Test::Exception)
BuildRequires: perl(Test::Memory::Cycle)
+BuildRequires: perl(Test::Moose)
BuildRequires: perl(Test::More) = 0.92
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
@@ -60,56 +58,56 @@ Requires: perl(Carp::Clan) = 6.0
Requires: perl(Class::Accessor::Grouped) = 0.09002
Requires: perl(Class::C3::Componentised) = 1.0005
Requires: perl(Class::Inspector) = 1.24
+Requires: perl(Context::Preserve) = 0.01
Requires: perl(Data::Dumper::Concise) = 1.000
Requires: perl(Data::Page) = 2.00
Requires: perl(DBI) = 1.609
-Requires: perl(List::Util) = 1.19
Requires: perl(Module::Find) = 0.06
Requires: perl(MRO::Compat) = 0.09
Requires: perl(Path::Class) = 0.18
-Requires: perl(Scalar::Util)
Requires: perl(Scope::Guard) = 0.03
Requires: perl(SQL::Abstract) = 1.61
Requires: perl(SQL::Abstract::Limit) = 0.13
-Requires: perl(Storable)
Requires: perl(Sub::Name) = 0.04
### Additional generated deps. These deps are regenerated from scratch every
### time this spec file is updated.
-# optional
rpms/perl-Text-CSV_XS/devel .cvsignore, 1.9, 1.10 perl-Text-CSV_XS.spec, 1.20, 1.21 sources, 1.9, 1.10
Author: cweyl
Update of /cvs/extras/rpms/perl-Text-CSV_XS/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv26918
Modified Files:
.cvsignore perl-Text-CSV_XS.spec sources
Log Message:
* Wed Mar 17 2010 Chris Weyl cw...@alumni.drew.edu 0.72-1
- PERL_INSTALL_ROOT = DESTDIR, add perl_default_filter (XS module)
- auto-update to 0.72 (by cpan-spec-update 0.01) (DBIx::Class needed a newer
Text::CSV, which in turn can only leverage Text::CSV_XS = 0.70)
- added a new br on perl(ExtUtils::MakeMaker) (version 0)
- added a new br on perl(IO::Handle) (version 0)
- added a new br on perl(Test::Harness) (version 0)
- added a new br on perl(Test::More) (version 0)
- added a new br on perl(Tie::Scalar) (version 0)
Index: .cvsignore
===
RCS file: /cvs/extras/rpms/perl-Text-CSV_XS/devel/.cvsignore,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- .cvsignore 2 Nov 2009 09:59:45 - 1.9
+++ .cvsignore 17 Mar 2010 01:19:28 - 1.10
@@ -1 +1 @@
-Text-CSV_XS-0.69.tgz
+Text-CSV_XS-0.72.tgz
Index: perl-Text-CSV_XS.spec
===
RCS file: /cvs/extras/rpms/perl-Text-CSV_XS/devel/perl-Text-CSV_XS.spec,v
retrieving revision 1.20
retrieving revision 1.21
diff -u -p -r1.20 -r1.21
--- perl-Text-CSV_XS.spec 4 Dec 2009 02:19:17 - 1.20
+++ perl-Text-CSV_XS.spec 17 Mar 2010 01:19:29 - 1.21
@@ -1,6 +1,6 @@
Name: perl-Text-CSV_XS
-Version:0.69
-Release:2%{?dist}
+Version:0.72
+Release:1%{?dist}
Summary:Comma-separated values manipulation routines
Group: Development/Libraries
@@ -11,8 +11,15 @@ BuildRoot: %{_tmppath}/%{name}-%{ve
BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(Test::Harness)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Tie::Scalar)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+%{?perl_default_filter}
+
%description
Text::CSV provides facilities for the composition and decomposition of
comma-separated values. An instance of the Text::CSV class can combine
@@ -31,7 +38,7 @@ make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type f -name '*.bs' -empty -exec rm -f {} ';'
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -55,6 +62,16 @@ rm -rf $RPM_BUILD_ROOT
%changelog
+* Wed Mar 17 2010 Chris Weyl cw...@alumni.drew.edu 0.72-1
+- PERL_INSTALL_ROOT = DESTDIR, add perl_default_filter (XS module)
+- auto-update to 0.72 (by cpan-spec-update 0.01) (DBIx::Class needed a newer
+ Text::CSV, which in turn can only leverage Text::CSV_XS = 0.70)
+- added a new br on perl(ExtUtils::MakeMaker) (version 0)
+- added a new br on perl(IO::Handle) (version 0)
+- added a new br on perl(Test::Harness) (version 0)
+- added a new br on perl(Test::More) (version 0)
+- added a new br on perl(Tie::Scalar) (version 0)
+
* Fri Dec 4 2009 Stepan Kasal ska...@redhat.com - 0.69-2
- rebuild against perl 5.10.1
Index: sources
===
RCS file: /cvs/extras/rpms/perl-Text-CSV_XS/devel/sources,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -p -r1.9 -r1.10
--- sources 2 Nov 2009 09:59:46 - 1.9
+++ sources 17 Mar 2010 01:19:29 - 1.10
@@ -1 +1 @@
-8788c57a50704265e35171746473b404 Text-CSV_XS-0.69.tgz
+1d51e67d11d22e31d2c8201a07321d86 Text-CSV_XS-0.72.tgz
--
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: [Bug 573896] initializing subtree with invalid syntax crashes ns-slapd
Subject: initializing subtree with invalid syntax crashes ns-slapd https://bugzilla.redhat.com/show_bug.cgi?id=573896 Files: ldap/servers/slapd/slap.h ldap/servers/slapd/task.c Description: When an import is executed using a task mechanism, slapi_task_log_notice is called for logging, where task_log field points the memory storing the log messages. If multiple log messages were logged by multiple worker threads simultaneously, there was a chance that the address of the log message was switched by realloc while the other threads were accessing the old address. This patch introduces task_log_lock per task to protect task_log. Note: slapi_ch_malloc and its friends never return NULL. They rather exits. Thus, to avoid the confusion which may look leaking the lock, I eliminated 2 error returns from slapi_task_log_notice. Proposed patch: https://bugzilla.redhat.com/attachment.cgi?id=400601action=diff https://bugzilla.redhat.com/attachment.cgi?id=400601action=edit smime.p7s Description: S/MIME Cryptographic Signature -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
