Koji or me at fault?
Hi, I've imported monodevelop-debugger-gdb for f13 and rawhide and have tried to build it. Koji is going through the setup, but then falling over on the build. Looking at the logs, it looks like a python problem... http://koji.fedoraproject.org/koji/taskinfo?taskID=2034431name=build.log Can anyone up the food chain verify where the problem is please? TTFN Paul -- Biggles was quietly reading his favourite book when Algy burst through the door. Distracted for a moment, Biggles surveyed what had happened and turned a page. Algy old man he said, clearing his throat, use the handle next time... - Taken from Biggles combs his Hair 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: Koji or me at fault?
On 03/06/2010 11:35 AM, Paul wrote: Hi, I've imported monodevelop-debugger-gdb for f13 and rawhide and have tried to build it. Koji is going through the setup, but then falling over on the build. Looking at the logs, it looks like a python problem... http://koji.fedoraproject.org/koji/taskinfo?taskID=2034431name=build.log Can anyone up the food chain verify where the problem is please? SRPM creation fails with: error: Bad source: /builddir/build/SOURCES/mdb-gdb-2-2.patch: No such file or directory Commit the patch file, tag, and try again. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fight bugs, not FESCo
On 06/03/10 10:04, Till Maas wrote: --snipped-- DB) 3) once a day a crawler reads all files and counts for each package how often they are installed, What about uninstalled? Update bring in upd to X, but package Y,Z. come in. User removes Y,Z without breaking anything. I am not really sure what problem you are seeing. What is supposed to break? Regards Till Take XFCE, user removes GDM install Slim. GDM was installed now is not, nothing is broken. Will GDM being uninstalled be accouted for, or will the install just matter? Like XFCE update tends to pull in nautilus. -- Regards, Frank Murphy UTF_8 Encoded -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re:Koji or me at fault?
make tag TAG_OPTS=-F make build 在2010-03-06?17:35:55，Paul?p...@all-the-johnsons.co.uk?写道： Hi, I've?imported?monodevelop-debugger-gdb?for?f13?and?rawhide?and?have tried?to?build?it.?Koji?is?going?through?the?setup,?but?then?falling over?on?the?build.?Looking?at?the?logs,?it?looks?like?a?python problem... http://koji.fedoraproject.org/koji/taskinfo?taskID=2034431name=build.log Can?anyone?up?the?food?chain?verify?where?the?problem?is?please? TTFN Paul --? Biggles?was?quietly?reading?his?favourite?book?when?Algy?burst?through the?door.?Distracted?for?a?moment,?Biggles?surveyed?what?had?happened and?turned?a?page.?Algy?old?man?he?said,?clearing?his?throat,?use?the handle?next?time...?-?Taken?from?Biggles?combs?his?Hair -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fight bugs, not FESCo
On Sat, Mar 06, 2010 at 11:19:27AM +, Frank Murphy wrote: On 06/03/10 10:04, Till Maas wrote: --snipped-- DB) 3) once a day a crawler reads all files and counts for each package how often they are installed, What about uninstalled? Update bring in upd to X, but package Y,Z. come in. User removes Y,Z without breaking anything. I am not really sure what problem you are seeing. What is supposed to break? Regards Till Take XFCE, user removes GDM install Slim. GDM was installed now is not, nothing is broken. Will GDM being uninstalled be accouted for, or will the install just matter? Yes, it will be honoured. The clients will send a list of installed packages. So after GDM is uninstalled, it will not be send anymore. The next time the crawler runs after the client updated his list, the GDM count will be effectively decremented. Regards Till pgpYE4Lp7GQpD.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: gcc internal error on F13
On Sat, Mar 06, 2010 at 08:44:13AM -0500, Sam Varshavchik wrote: Paulo Cavalcanti writes: « HTML content follows » I am trying to build a package on F13, and got a gcc internal error: URL:http://koji.fedoraproject.org/koji/taskinfo?taskID=2034791http://koji .fedoraproject.org/koji/taskinfo?taskID=2034791 I have no idea how to proceed Create a bug against gcc. Given that the bug is preventing a package build, it should be a high priority bug to fix. Well, in this case it is not clear whether it is a gcc bug. gcc was OOM killed by the kernel, whether it is a gcc bug or not depends on whether gcc uses way too much memory compared to how complicated/large the source is. The OOM could be very well caused by some other memory demanding build going on at the same time on the same build box. So, first try to build it again, and only if it fails on the same file again, preprare a preprocessed source and file a bug against gcc. Jakub -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100306 changes
Compose started at Sat Mar 6 08:15:05 UTC 2010 Broken deps for i386 -- blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 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 1:libguestfs-1.0.85-1.fc14.i686 requires /usr/lib/libkadm5clnt.so.6 1:libguestfs-1.0.85-1.fc14.i686 requires /usr/lib/libkadm5srv.so.6 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 maniadrive-1.2-20.fc14.i686 requires libphp5-5.3.1.so maniadrive-track-editor-1.2-20.fc14.i686 requires libphp5-5.3.1.so 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 perl-Authen-Krb5-Admin-0.11-5.fc13.i686 requires libkadm5clnt.so.6(kadm5clnt_6_MIT) perl-Authen-Krb5-Admin-0.11-5.fc13.i686 requires libkadm5clnt.so.6 pyclutter-gst-0.9.2-1.fc12.i686 requires libclutter-gst-0.10.so.0 qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13
Another great update
While we are at it, here is another great update: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326 * New version introduced in F11. * Doesn't fix any bugs but it's an enhancement only. * Useless update description update to 4.7.1. * And *of course* it was pushed directly to stable, even in F-13. Dear maintainers, please stop this! Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Hi, 2010/3/6 Christoph Wickert christoph.wick...@googlemail.com: While we are at it, here is another great update: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326 * New version introduced in F11. * Doesn't fix any bugs but it's an enhancement only. * Useless update description update to 4.7.1. * And *of course* it was pushed directly to stable, even in F-13. Dear maintainers, please stop this! Regards, Christoph Is there any Fedora update policy? Because I don't understand the criteria for Fedora package update. Why I can install KDE 4.4 in F11 and I can't install latest gnome? (I'm just asking because I'm curious, not because I use Linux on desktop) From my user point of view, I would prefer to don't have any significant updates in previous stable version - just security fixes. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski: Hi, 2010/3/6 Christoph Wickert christoph.wick...@foomail.com: While we are at it, here is another great update: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326 * New version introduced in F11. * Doesn't fix any bugs but it's an enhancement only. * Useless update description update to 4.7.1. * And *of course* it was pushed directly to stable, even in F-13. Dear maintainers, please stop this! Regards, Christoph Is there any Fedora update policy? Not yet, but we are working on it, see http://jwboyer.livejournal.com/36737.html Because I don't understand the criteria for Fedora package update. Why I can install KDE 4.4 in F11 and I can't install latest gnome? Because the KDE SIG uses different criteria than most of the other packagers. From my user point of view, I would prefer to don't have any significant updates in previous stable version - just security fixes. Fully agreed, but this is something we are discussing for the last two weeks and I don't expect an agreement in the near future. While I think that the decision about an update should generally be up to the maintainers, I think KDE or this update show that we were better off with an official policy. Regards, Michal Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 06, 2010 at 06:49:03PM +0100, Christoph Wickert wrote: maintainers, I think KDE or this update show that we were better off with an official policy. Did the mc update break something? Regards Till pgpdxHb1B1LoX.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 03/06/2010 11:28 PM, Till Maas wrote: On Sat, Mar 06, 2010 at 06:49:03PM +0100, Christoph Wickert wrote: maintainers, I think KDE or this update show that we were better off with an official policy. Did the mc update break something? Even if it did not it would be useful to get a proper description of what the updates involves and as the current guidelines recommend a summary of the changes or link to the upstream changelog Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/6 Christoph Wickert christoph.wick...@googlemail.com: Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski: Hi, 2010/3/6 Christoph Wickert christoph.wick...@foomail.com: While we are at it, here is another great update: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326 * New version introduced in F11. * Doesn't fix any bugs but it's an enhancement only. * Useless update description update to 4.7.1. * And *of course* it was pushed directly to stable, even in F-13. Dear maintainers, please stop this! Regards, Christoph Is there any Fedora update policy? Not yet, but we are working on it, see http://jwboyer.livejournal.com/36737.html Because I don't understand the criteria for Fedora package update. Why I can install KDE 4.4 in F11 and I can't install latest gnome? Because the KDE SIG uses different criteria than most of the other packagers. From my user point of view, I would prefer to don't have any significant updates in previous stable version - just security fixes. Fully agreed, but this is something we are discussing for the last two weeks I have seen some discussions, but I don't follow them. I'm waiting for results ;) and I don't expect an agreement in the near future. Pity. There are many Fedora policies that are useless for end users like me, but update policy would be quite usefull. While I think that the decision about an update should generally be up to the maintainers, I think KDE or this update show that we were better off with an official policy. Regards, Michal Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/6 Naheem Zaffar naheemzaf...@gmail.com: 2010/3/6 Michał Piotrowski mkkp...@gmail.com Why I can install KDE 4.4 in F11 and I can't install latest gnome? (I'm just asking because I'm curious, not because I use Linux on desktop) I think for many people the issue is not that it can be an update (maybe the enhancements etc are useful to someone). As an end user, I would think there should be asafety precaution on non urgent updates to go through updates-testing. FTR, I DO like and want feature updates. Updates-testing will not catch everything, but it should help catch soime nuclear issues that otherwise may have sneaked past. I think the current update process is very good and well liked by me. But tweaking it is not a big problem. PS other places that have more stable updates also have their problems - there are many users who dislike Ubuntu because bugs are not fixed and they have to live with them far too long. I generally agree with your POV for actual stable F12 - latest and greatest updates for peoples who likes bleeding edge. But previous stable (F11) IMHO should be considered as in maintenance mode - security and bug fixes only. Just my 0.02 $. Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: X server configuration changes
On Thu, Feb 18, 2010 at 12:36 AM, Rajeesh K Nambiar rajeeshknamb...@gmail.com wrote: On Thu, Feb 18, 2010 at 4:29 AM, Peter Hutterer peter.hutte...@who-t.net wrote: Rajeesh K Nambiar wrote: Any pointers on how to migrate the 'enable touchpad tap-to-click' feature from the existing .fdi file(s)? Section InputClass Identifier tap-by-default MatchIsTouchpad on Option TapButton1 1 EndSection drop that into your xorg.conf(.d) and restart the server, that should do it. Once you got it working to your liking, please do me a favour and add this to the wiki page as an example configuration - I'm sure it'll help others too. Going to try it out in the weekend. Sorry - got time to test only today. I had downloaded the Live image from Rawhide nightly build - desktop-x86_64-20100227.20.iso and added the configuration file to the /etc/xorg.conf.d/, and it works well at the GDM login screen. I have also added this to the wiki page (http://fedoraproject.org/wiki/Input_device_configuration#Device_configuration) now. Once again, thanks Peter! -- Cheers, Rajeesh http://rajeeshknambiar.wordpress.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Update question: some user data
I thought to myself yesterday, 'what this long and fractious thread about update policy *really* needs is some unscientific and controversial numbers'. =) So, I ran a forum poll! Everyone loves those, right? Here it is: http://forums.fedoraforum.org/showthread.php?t=241710 I tried to present the poll in a very neutral way, and as far as I know, it hasn't been linked to from anywhere else; only regular forum members are likely to come across it. So it shouldn't be massively inherently biased, and has a reasonable shot of giving us a vague idea of what some Real Fedora Users think. The numbers do surprise me, to be honest. As I write this, it's 34-8 - that's over 80% - in favour of 'adventurous' updates. A lot of the replies make it clear that people really do see being 'bleeding edge' as being a part of Fedora's nature, and a part of the reason why they run it. I wouldn't honestly have expected that; I'd have expected much closer to a 50/50 split if anything. A lot of people explicitly say things like 'I run Fedora so I can have the latest stuff on my desktop, if I want a more conservative system I'll run CentOS'. No, the voting numbers aren't huge, but it's still some kind of data. I can promote the poll to the forum front page to try and get more input, if desired. What do people make of this? -- 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: Upcoming Bugzilla Changes
On Fri, Mar 05, 2010 at 08:14:38AM -0800, Adam Williamson wrote: On Fri, 2010-03-05 at 13:27 +0100, Till Maas wrote: Especially it needs to be made sure that only bugs created prior to adding F13 to RedHat Bugzilla or the branching of F13, depending on what happened later, are touched by the Rawhide bug rebase. We already did that, though tk009 forgot to mention it. If you look at the proposed query, it's cut off at the date of the branch announcement. The query I was given in IRC does not take into account, which version was specified when the bug was created. In the other subthread I provided a script to work around this limitation. Regards Till pgp9oMp1IwtNu.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On 3/6/2010 9:04 PM, Adam Williamson wrote: I thought to myself yesterday, 'what this long and fractious thread about update policy *really* needs is some unscientific and controversial numbers'. =) So, I ran a forum poll! Everyone loves those, right? What do people make of this? I think that the poll misses an important distinction. People running f11 are very likely to have a different opinion than people running f12. The responders should indicate which system they are using. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: proven packager needed - mrpt
Am Samstag, den 06.03.2010, 19:03 +0100 schrieb Haïkel Guémar: Following the previous thread on opencv: http://lists.fedoraproject.org/pipermail/devel/2010-February/131584.html Almost all packages have been rebuilt against opencv-2.0.0-7 (thank you, guys !) except mrpt. We didn't get any news from mrpt only maintainer jlblanco and most packages have been pushed to stable . I need a proven packager to rebuild mrpt (a simple recompilation should be fine) so i could push opencv-2.0.0-7 into stable as soon as possible. devel and F-13 is build: http://koji.fedoraproject.org/koji/taskinfo?taskID=2035621 http://koji.fedoraproject.org/koji/taskinfo?taskID=2035760 Please edit your opencv update and add mrpt-0.8.0-0.3.20100102svn1398.fc13 to the packages, so this is pushed to stable, when your package is pushed to stable. (I believe, you just need provenpackager rights to commit to cvs, but not for shipping the update...) Thomas -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-13 Branched report: 20100306 changes
Compose started at Sat Mar 6 09:15:12 UTC 2010 Broken deps for i386 -- blahtexml-0.6-5.fc12.i686 requires libxerces-c.so.28 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 gnome-python2-totem-2.29.1-4.fc13.i686 requires libtotem-plparser.so.12 koan-2.0.3.1-1.fc13.noarch requires mkinitrd 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 libvirt-qpid-0.2.17-3.fc12.i686 requires qpidc = 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 matahari-0.0.4-7.fc13.i686 requires qpidc = 0:0.5.819819 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-facedetect-1.0.0-4.fc13.i686 requires libhighgui.so.2.0 php-facedetect-1.0.0-4.fc13.i686 requires libcvaux.so.2.0 php-facedetect-1.0.0-4.fc13.i686 requires libcv.so.2.0 php-facedetect-1.0.0-4.fc13.i686 requires libcxcore.so.2.0 player-3.0.1-5.fc13.i686 requires libml.so.2.0 player-3.0.1-5.fc13.i686 requires libhighgui.so.2.0 player-3.0.1-5.fc13.i686 requires libcxcore.so.2.0 player-3.0.1-5.fc13.i686 requires libcv.so.2.0 player-3.0.1-5.fc13.i686 requires libcvaux.so.2.0 qmf-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-devel-0.5.819819-4.fc13.i686 requires qpidc-client-devel = 0:0.5.819819-4.fc13 qpidc-server-rdma-0.5.819819-4.fc13.i686 requires qpidc-client-rdma = 0:0.5.819819-4.fc13 qpidc-server-ssl-0.5.819819-4.fc13.i686 requires qpidc-client-ssl = 0:0.5.819819-4.fc13 zikula-module-menutree-2.2-1.fc13.noarch requires zikula = 0:1.2 Broken deps for x86_64 -- blahtexml-0.6-5.fc12.x86_64 requires libxerces-c.so.28()(64bit) 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) gnome-python2-totem-2.29.1-4.fc13.x86_64 requires libtotem-plparser.so.12()(64bit) koan-2.0.3.1-1.fc13.noarch requires mkinitrd 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libglib-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.i686 requires /lib/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgthread-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgio-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgmodule-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libgobject-2.0.so.0.2303.0 1:libguestfs-1.0.84-2.fc13.x86_64 requires /lib64/libglib-2.0.so.0.2303.0 libvirt-qpid-0.2.17-3.fc12.x86_64 requires qpidc = 0:0.5.790661 linphone-2.1.1-4.fc12.i686 requires libortp.so.7 linphone-2.1.1-4.fc12.x86_64 requires libortp.so.7()(64bit) matahari-0.0.4-7.fc13.x86_64 requires qpidc = 0:0.5.819819 ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-facedetect-1.0.0-4.fc13.x86_64 requires libcv.so.2.0()(64bit) php-facedetect-1.0.0-4.fc13.x86_64 requires libcxcore.so.2.0()(64bit) php-facedetect-1.0.0-4.fc13.x86_64 requires libcvaux.so.2.0()(64bit) php-facedetect-1.0.0-4.fc13.x86_64 requires libhighgui.so.2.0()(64bit) player-3.0.1-5.fc13.i686 requires libml.so.2.0 player-3.0.1-5.fc13.i686 requires libhighgui.so.2.0 player-3.0.1-5.fc13.i686 requires libcxcore.so.2.0 player-3.0.1-5.fc13.i686 requires libcv.so.2.0 player-3.0.1-5.fc13.i686 requires libcvaux.so.2.0 player-3.0.1-5.fc13.x86_64 requires libcvaux.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires libcv.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires libml.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires libcxcore.so.2.0()(64bit) player-3.0.1-5.fc13.x86_64 requires
Re: Another great update
On Saturday, 06 March 2010 at 18:49, Christoph Wickert wrote: Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski: [...] Because I don't understand the criteria for Fedora package update. Why I can install KDE 4.4 in F11 and I can't install latest gnome? Because the KDE SIG uses different criteria than most of the other packagers. How do you know what criteria most packagers use? I assume you have done some analysis, since you stated that so authoritatively. Can we see your analysis? Regards, R. -- Fedora http://fedoraproject.org/wiki/User:Rathann RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu Faith manages. -- Delenn to Lennier in Babylon 5:Confessions and Lamentations -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On Sat, Mar 6, 2010 at 8:04 PM, Adam Williamson awill...@redhat.com wrote: I thought to myself yesterday, 'what this long and fractious thread about update policy *really* needs is some unscientific and controversial numbers'. =) So, I ran a forum poll! Everyone loves those, right? Here it is: http://forums.fedoraforum.org/showthread.php?t=241710 I tried to present the poll in a very neutral way, and as far as I know, it hasn't been linked to from anywhere else; only regular forum members are likely to come across it. So it shouldn't be massively inherently biased, and has a reasonable shot of giving us a vague idea of what some Real Fedora Users think. The numbers do surprise me, to be honest. As I write this, it's 34-8 - that's over 80% - in favour of 'adventurous' updates. A lot of the replies make it clear that people really do see being 'bleeding edge' as being a part of Fedora's nature, and a part of the reason why they run it. I wouldn't honestly have expected that; I'd have expected much closer to a 50/50 split if anything. A lot of people explicitly say things like 'I run Fedora so I can have the latest stuff on my desktop, if I want a more conservative system I'll run CentOS'. No, the voting numbers aren't huge, but it's still some kind of data. I can promote the poll to the forum front page to try and get more input, if desired. What do people make of this? I think that was a very good idea. And it shows what i meant with the face and character of Fedora, in one of the other threads. -- LG Thomas Dubium sapientiae initium -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On Sat, 6 Mar 2010, Adam Williamson wrote: I thought to myself yesterday, 'what this long and fractious thread about update policy *really* needs is some unscientific and controversial numbers'. =) So, I ran a forum poll! Everyone loves those, right? Here it is: http://forums.fedoraforum.org/showthread.php?t=241710 I tried to present the poll in a very neutral way, and as far as I know, it hasn't been linked to from anywhere else; only regular forum members are likely to come across it. So it shouldn't be massively inherently biased, and has a reasonable shot of giving us a vague idea of what some Real Fedora Users think. The numbers do surprise me, to be honest. As I write this, it's 34-8 - that's over 80% - in favour of 'adventurous' updates. A lot of the replies make it clear that people really do see being 'bleeding edge' as being a part of Fedora's nature, and a part of the reason why they run it. I wouldn't honestly have expected that; I'd have expected much closer to a 50/50 split if anything. A lot of people explicitly say things like 'I run Fedora so I can have the latest stuff on my desktop, if I want a more conservative system I'll run CentOS'. No, the voting numbers aren't huge, but it's still some kind of data. I can promote the poll to the forum front page to try and get more input, if desired. What do people make of this? I don't think people realize what they're asking for. I'll just defer to my favorite Ford quote: If I had asked my customers what they wanted, Ford said, they would have said a faster horse. The best part of all of this is, it doesn't matter anymore. We've let Fedora go completely directionless for years now. If we listen to the users, they'll all tell us different things. Especially if you get a sample size large enough (your poll isn't anywhere near large enough to be scientific which is why you called it unscientific :) Ahwell, back to designing by committee because that works so well. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Am Samstag, den 06.03.2010, 19:30 +0100 schrieb Michał Piotrowski: I have seen some discussions, but I don't follow them. I'm waiting for results ;) Get involved, try to influence the discussion. Pity. There are many Fedora policies that are useless for end users like me, but update policy would be quite usefull. Then you should at least vote at: http://forums.fedoraforum.org/showthread.php?t=241710 Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Am Samstag, den 06.03.2010, 21:10 +0100 schrieb Dominik 'Rathann' Mierzejewski: On Saturday, 06 March 2010 at 18:49, Christoph Wickert wrote: Am Samstag, den 06.03.2010, 18:17 +0100 schrieb Michał Piotrowski: [...] Because I don't understand the criteria for Fedora package update. Why I can install KDE 4.4 in F11 and I can't install latest gnome? Because the KDE SIG uses different criteria than most of the other packagers. How do you know what criteria most packagers use? I assume you have done some analysis, since you stated that so authoritatively. Can we see your analysis? I didn't state anything authoritatively and what I described is what everybody who looks at https://admin.fedoraproject.org/updates will see. He will see huge KDE updates like https://admin.fedoraproject.org/updates/search/kdebase-runtime By taking a closer look he will then see that KDE in F11 was released with KDE 4.2.2, then updated to 4.2.3, then 4.2.4, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.3.5 and finally to 4.4.0. This means that kdebase-workspace is one of the most updated packages in Fedora: https://admin.fedoraproject.org/updates/metrics/?release=F11 Most of our packagers follow the guidelines from the wiki: http://fedoraproject.org/wiki/Package_update_guidelines This means, they apply at least three criteria: * An update should not break something * An update should be backwards compatible, e.g. it should not change the syntax or location of a config file so that old settings can no longer be applied. * An update should not change the behavior of an basic application, e.g. think of when Thunderbird started indexing automatically after an update. Summing it all up I think I don't think it is pretty obvious that the KDE SIG uses different criteria then most other maintainers. This is just a statement and no criticism. Regards, R. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Am Samstag, den 06.03.2010, 19:38 +0100 schrieb Michał Piotrowski: 2010/3/6 Naheem Zaffar naheemzaf...@gmail.com: [snipped] PS other places that have more stable updates also have their problems - there are many users who dislike Ubuntu because bugs are not fixed and they have to live with them far too long. Nobody is talking about bugfix updates here. Bugfixes are always allowed. I generally agree with your POV for actual stable F12 - latest and greatest updates for peoples who likes bleeding edge. But previous stable (F11) IMHO should be considered as in maintenance mode - security and bug fixes only. +1, Michał! People who want the latest and greatest have already updated to F12 months ago anyway, so there is not much use in pushing new versions to F11. Regards, Christoph -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Expect more positive bodhi karma / check karma automatism
Good news everyone, you can probably expect to receive more positive bodhi karma for your updates in the future (or you already got unexpected much), because there is now a script called 'fedora-easy-karma'[0], that makes providing feedback a lot easier. This makes it more important to consider the karma automatism for your updates. By default testing updates updates are declared stable when they get three karma points. In the past this probably never happened, but now I have seen several updates, where this occurred. So if you think your package should stay longer in testing or needs more intensive testing than the average updates, consider disabling the karma automatism or select a higher threshold for the automatic push to happen. Regards Till [0] https://fedoraproject.org/wiki/Fedora_Easy_Karma pgpqOcw7LjFTR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote: +1, Michał! People who want the latest and greatest have already updated to F12 months ago anyway, so there is not much use in pushing new versions to F11. Why? I don't want to update/reinstall all my machines every 6 months. And I expect the same amount of latestness an greatestness from F-11 and F-12. And I am not alone. (See the discussions in the devel list for the last 2 weeks. When version X of a software is supported in F-12, the same version X can be supported most of the time in F-11. And if it can be supported, it should be supported. However, this mc update should have gone to testing and stayed there for a couple weeks before pushed to stable. I agree at that point. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Update question: some user data
On 03/07/2010 12:34 AM, Adam Williamson wrote: I thought to myself yesterday, 'what this long and fractious thread about update policy *really* needs is some unscientific and controversial numbers'. =) So, I ran a forum poll! Everyone loves those, right? Here it is: http://forums.fedoraforum.org/showthread.php?t=241710 No, the voting numbers aren't huge, but it's still some kind of data. I can promote the poll to the forum front page to try and get more input, if desired. What do people make of this? I have promoted the poll to the front page in an effort to gather more numbers and the stats are beginning to look different and if you want a better measurement you can post in your blog and to the user mailing list etc and gather more votes Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 06, 2010 at 11:16:45PM +0100, Christoph Wickert wrote: Am Samstag, den 06.03.2010, 19:38 +0100 schrieb Michał Piotrowski: 2010/3/6 Naheem Zaffar naheemzaf...@gmail.com: [snipped] PS other places that have more stable updates also have their problems - there are many users who dislike Ubuntu because bugs are not fixed and they have to live with them far too long. Nobody is talking about bugfix updates here. Bugfixes are always allowed. There are also proponents who want less bug fixes to lower the chances of regressions. Btw. upstream releases most often contain bug fixes, even if they also contain new features. Regards Till pgphiH81rmtzk.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Adding optional packages to comps.xml
As there are no objections I have added to Sound and Video v4l2ucp in comps.xml for F12-F14, ucview for F11-F14, EL5 (Robert Scheck replied that I can do it) and gtk-v4l for F13-F14. Alexey Kurov nuc...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/6 Orcan Ogetbil oget.fed...@gmail.com: On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote: +1, Michał! People who want the latest and greatest have already updated to F12 months ago anyway, so there is not much use in pushing new versions to F11. Why? I don't want to update But you are updating to latest KDE in f11. So what is the deal with full system update? /reinstall all my machines every 6 months. And I expect the same amount of latestness an greatestness from F-11 and F-12. And I am not alone. (See the discussions in the devel list for the last 2 weeks. When version X of a software is supported in F-12, the same version X can be supported most of the time in F-11. And if it can be supported, it should be supported. Ok, but what is the point of previous stable version then? If you have the same software in F11 and F12, I really don't see the reason to support f11. Just update all machines to f12... OTOH - don't release F13 - just push updates to F12 - will be the same thing ;) I hope you get my POV. However, this mc update should have gone to testing and stayed there for a couple weeks before pushed to stable. I agree at that point. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 03/07/2010 12:25 AM, Orcan Ogetbil wrote: On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote: +1, Michał! People who want the latest and greatest have already updated to F12 months ago anyway, so there is not much use in pushing new versions to F11. Why? I don't want to update/reinstall all my machines every 6 months. And I expect the same amount of latestness an greatestness from F-11 and F-12. And I am not alone. (See the discussions in the devel list for the last 2 weeks. When version X of a software is supported in F-12, the same version X can be supported most of the time in F-11. And if it can be supported, it should be supported. I'd personally want to be able to _choose_ if and when I want to get all the new stuff. If I have time, I upgrade to new Fedora release and happily deal with all the problems that come up. This is exactly what new distro releases are for -- people prepare for the upgrade and take time to do it. But what happened now is that a major Desktop Environment version was dumped in a stable Fedora release, and it annoyed some people (me included). If the new version had only come with F-13 instead, then I'd have an option to choose _when_ I want to upgrade from F-12 to F-13 to deal with the problems that might arise with the new version. But if the new version is dumped upon me in the middle of a week, I'm left without a choice. I have to immediately deal with whatever problems arise from the upgrade. Now think how someone who administers more than one computer would react to that -- I'm sure they also want to choose when to get major upgrades so that they could upgrade when they feel they have enough time for that. So yes, I'd prefer to upgrade (not reinstall! as you said) once every 6 months, instead of having to deal with changing expectations every single day. -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 6, 2010 at 5:48 PM, Kalev Lember wrote: On 03/07/2010 12:25 AM, Orcan Ogetbil wrote: On Sat, Mar 6, 2010 at 5:16 PM, Christoph Wickert wrote: +1, Michał! People who want the latest and greatest have already updated to F12 months ago anyway, so there is not much use in pushing new versions to F11. Why? I don't want to update/reinstall all my machines every 6 months. And I expect the same amount of latestness an greatestness from F-11 and F-12. And I am not alone. (See the discussions in the devel list for the last 2 weeks. When version X of a software is supported in F-12, the same version X can be supported most of the time in F-11. And if it can be supported, it should be supported. I'd personally want to be able to _choose_ if and when I want to get all the new stuff. If I have time, I upgrade to new Fedora release and happily deal with all the problems that come up. This is exactly what new distro releases are for -- people prepare for the upgrade and take time to do it. But what happened now is that a major Desktop Environment version was dumped in a stable Fedora release, and it annoyed some people (me included). If the new version had only come with F-13 instead, then I'd have an option to choose _when_ I want to upgrade from F-12 to F-13 to deal with the problems that might arise with the new version. But if the new version is dumped upon me in the middle of a week, I'm left without a choice. I have to immediately deal with whatever problems arise from the upgrade. Now think how someone who administers more than one computer would react to that -- I'm sure they also want to choose when to get major upgrades so that they could upgrade when they feel they have enough time for that. So yes, I'd prefer to upgrade (not reinstall! as you said) once every 6 months, instead of having to deal with changing expectations every single day. Thus you have the option of not doing an update every day. Moreover you also have the option of updating security fixes only. Yet moreover you also have the option of updating bugfixes in addition, leaving the enhancement updates out. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sun, Mar 07, 2010 at 12:48:23AM +0200, Kalev Lember wrote: deal with the problems that might arise with the new version. But if the new version is dumped upon me in the middle of a week, I'm left without a choice. I have to immediately deal with whatever problems arise from the upgrade. Now think how someone who administers more than one You do not have to update immediately and for security updates you can use yum --security update or PackageKit. Regards Till pgpu8iA1c25f8.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 03/07/2010 04:14 AM, Michał Piotrowski wrote: I'm just a guest here :) I'm not a Fedora developer so my vote doesn't really matter. Getting involved does not require a vote and any user position if expressed in a constructive fashion does matter and is part of how we can form a decision Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/6 Michał Piotrowski: 2010/3/6 Orcan Ogetbil: The numbers 11, 12 should only indicate the core components revision number . I'm not convinced to this philosophy. I have used a few Linux distros in past 11 years, and this is something new to me... I understand that. However there are philosophies that don't convince me either. If you consider gtk2-2.18 to be stable enough to support in Fedora 12, then why can't you support it in F-11? Laziness? Lack of manpower? Is it because F-11 is supposed to be more stable than F-12? Then why do we stop supporting F-11 (such a stable release by this logic) after only a couple months? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote: 2010/3/6 Michał Piotrowski : But you are updating to latest KDE in f11. So what is the deal with full system update? Time. A simple yum update or make a selective update takes a few minutes. A whole system update takes more. I've been upgrading my systems for a few years now with a simple yum upgrade, i.e. install the new fedora-release package and run yum update. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 03/07/2010 12:52 AM, Orcan Ogetbil wrote: Yet moreover you also have the option of updating bugfixes in addition, leaving the enhancement updates out. I really don't think I have that option. It might work in some cases, but generally it's bound to fail. A security update in an application which uses KDE or Qt libs (both of which were upgraded to a new feature release recently in F-11 and F-12) will be built against those new libs. It's a common practice that new versions of libraries continue working with programs that were compiled against an older version of said library. But it doesn't work the other way around: something built against Qt 4.5 is supposed to continue working with Qt 4.6, but an application built against Qt 4.6 will have no guarantees that it also runs with Qt 4.5. This is the reason why only applying security updates doesn't work if underlying libraries get upgraded to new feature releases meanwhile. Let me quote mail titled Read this if your package BuildRequires qt(4)-devel!!! here. On 02/22/2010 05:40 AM, Kevin Kofler wrote: for all maintainers of packages which BuildRequire qt4-devel (or qt-devel, but the versioned virtual Provides is preferred): please, when you plan to push updates for your packages, ALWAYS CHECK what version of Qt your package got built against and DO NOT PUSH your update to stable before that version of Qt goes stable! A package built against Qt 4.6 WILL NOT WORK AT ALL with Qt 4.5!!! (This is always the case, Qt is backwards- but not forwards- compatible.) -- Kalev -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 6, 2010 at 6:16 PM, Jussi Lehtola wrote: On Sat, 2010-03-06 at 17:48 -0500, Orcan Ogetbil wrote: 2010/3/6 Michał Piotrowski : But you are updating to latest KDE in f11. So what is the deal with full system update? Time. A simple yum update or make a selective update takes a few minutes. A whole system update takes more. I've been upgrading my systems for a few years now with a simple yum upgrade, i.e. install the new fedora-release package and run yum update. That broke stuff for me in the past. It might have changed since. Yet I feel the need to clone the root partition to somewhere before attempting again, which, with limited hardware supplies, takes time. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sun, Mar 07, 2010 at 01:28:32AM +0200, Kalev Lember wrote: On 03/07/2010 12:52 AM, Orcan Ogetbil wrote: Yet moreover you also have the option of updating bugfixes in addition, leaving the enhancement updates out. I really don't think I have that option. It might work in some cases, but generally it's bound to fail. But you have nothing to loose if you try it. You won't get more updates than without trying to reduce them to the security updates. Even if it might in theory not work that good, maybe it does in practice. Regards Till pgpKHgfBVSFKR.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Em Sáb, 2010-03-06 às 18:00 +0100, Christoph Wickert escreveu: While we are at it, here is another great update: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326 * New version introduced in F11. * Doesn't fix any bugs but it's an enhancement only. * Useless update description update to 4.7.1. * And *of course* it was pushed directly to stable, even in F-13. Dear maintainers, please stop this! Regards, Christoph A few days ago the discussion on policy updates are maturing and that it is beneficial to Fedora, but it's useless to start threads with the attitude of pointing fingers and accusing using an ironic tone. -- Henrique Junior henrique...@gmail.com signature.asc Description: Esta é uma parte de mensagem assinada digitalmente -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Provide more testing feedback (was: Re: Refining the update queues/process)
On Thu, Mar 04, 2010 at 05:32:11PM +0100, Till Maas wrote: can be packaged. Another obvious TODO is to get bodhi_update_str() included in the bodhi client in fedora-python. I'll be happy to take that patch. Looking like I'll be pushing out an updated python-fedora next week. Depending on the timing of the packagedb update, I may push out another python-fedora soon afterwards or hold off on the python-fedora update until I can push it alongside the new pkgdb. -Toshio pgppAN88K84we.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Orcan Ogetbil wrote: Moreover you also have the option of updating security fixes only. That option doesn't really exist, as was already demonstrated: http://lists.fedoraproject.org/pipermail/devel/2010-March/131926.html Björn Persson 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: Expect more positive bodhi karma / check karma automatism
On 6.3.2010 23:21, Till Maas wrote: Good news everyone, you can probably expect to receive more positive bodhi karma for your updates in the future (or you already got unexpected much), because there is now a script called 'fedora-easy-karma'[0], that makes providing feedback a lot easier. Till, great job, thank you! Also thanks for packaging that immediately -- what about installing it by default? It's a tiny package and we really do want our users to provide feedback. Best, Milos -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/7 Orcan Ogetbil oget.fed...@gmail.com: 2010/3/6 Michał Piotrowski: 2010/3/6 Orcan Ogetbil: The numbers 11, 12 should only indicate the core components revision number . I'm not convinced to this philosophy. I have used a few Linux distros in past 11 years, and this is something new to me... I understand that. However there are philosophies that don't convince me either. If you consider gtk2-2.18 to be stable enough to support in Fedora 12, then why can't you support it in F-11? Laziness? Lack of manpower? Is it because F-11 is supposed to be more stable than F-12? Then why do we stop supporting F-11 (such a stable release by this logic) after only a couple months? Let's consider a situation - I'm developing a project in php 5.2. This project might work fine on php 5.3 - I don't know I didn't tested it yet. I'm depending on 5.2 version. Testing this code for a new php will take some time. Php 5.3 is considered as stable in F12 - fine for me, but IMHO should never be considered as an update for F11. Some people depend on some constant values here - php 5.2, postgres 8.3 etc. I know that there is a RHEL5/CentOS5 for such things, but this is pretty outdated OS for my needs. Orcan Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 6, 2010 at 6:28 PM, Kalev Lember wrote: On 03/07/2010 12:52 AM, Orcan Ogetbil wrote: Yet moreover you also have the option of updating bugfixes in addition, leaving the enhancement updates out. I really don't think I have that option. It might work in some cases, but generally it's bound to fail. A security update in an application which uses KDE or Qt libs (both of which were upgraded to a new feature release recently in F-11 and F-12) will be built against those new libs. It's a common practice that new versions of libraries continue working with programs that were compiled against an older version of said library. But it doesn't work the other way around: something built against Qt 4.5 is supposed to continue working with Qt 4.6, but an application built against Qt 4.6 will have no guarantees that it also runs with Qt 4.5. This is the reason why only applying security updates doesn't work if underlying libraries get upgraded to new feature releases meanwhile. Let me quote mail titled Read this if your package BuildRequires qt(4)-devel!!! here. You are correct. But we are talking about Fedora, right? Going to the latest is the ultimate goal. The question is: when? This is the reason why I believe in extensive use of updates-testing. Big updates such as the one you pointed above should stay in testing for a longer period of time, until it is safe for most to update. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/6 Michał Piotrowski mkkp...@gmail.com: 2010/3/7 Orcan Ogetbil oget.fed...@gmail.com: 2010/3/6 Michał Piotrowski: 2010/3/6 Orcan Ogetbil: The numbers 11, 12 should only indicate the core components revision number . I'm not convinced to this philosophy. I have used a few Linux distros in past 11 years, and this is something new to me... I understand that. However there are philosophies that don't convince me either. If you consider gtk2-2.18 to be stable enough to support in Fedora 12, then why can't you support it in F-11? Laziness? Lack of manpower? Is it because F-11 is supposed to be more stable than F-12? Then why do we stop supporting F-11 (such a stable release by this logic) after only a couple months? Let's consider a situation - I'm developing a project in php 5.2. This project might work fine on php 5.3 - I don't know I didn't tested it yet. I'm depending on 5.2 version. Testing this code for a new php will take some time. Php 5.3 is considered as stable in F12 - fine for me, but IMHO should never be considered as an update for F11. Some people depend on some constant values here - php 5.2, postgres 8.3 etc. I know that there is a RHEL5/CentOS5 for such things, but this is pretty outdated OS for my needs. Again I say updates-testing! Leaving php-5.3 in testing on F-11 for a couple months will warn the users what is coming up and gives them plenty of time to adapt. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Why? I don't want to update/reinstall all my machines every 6 months. Since you don't want to update every 6 months, you want people to keep updating every now and then? Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 03/07/2010 06:47 AM, Orcan Ogetbil wrote: Again I say updates-testing! Leaving php-5.3 in testing on F-11 for a couple months will warn the users what is coming up and gives them plenty of time to adapt. If you have a large codebase two months is barely enough time to even big evaluating a move Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/7 Rahul Sundaram methe...@gmail.com: On 03/07/2010 06:47 AM, Orcan Ogetbil wrote: Again I say updates-testing! Leaving php-5.3 in testing on F-11 for a couple months will warn the users what is coming up and gives them plenty of time to adapt. If you have a large codebase two months is barely enough time to even big evaluating a move True. The other thing is that I don't plan to stick with Fedora on servers. I want to move to CentOS6. I don't know which version of php will be included there, so moving forward is not an option now. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On 6 March 2010 17:00, Christoph Wickert christoph.wick...@googlemail.com wrote: While we are at it, here is another great update: https://admin.fedoraproject.org/updates/F11/FEDORA-2010-3326 * New version introduced in F11. * Doesn't fix any bugs but it's an enhancement only. * Useless update description update to 4.7.1. * And *of course* it was pushed directly to stable, even in F-13. Dear maintainers, please stop this! What broke for you in this update? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 6, 2010 at 8:20 PM, Rahul Sundaram wrote: On 03/07/2010 06:47 AM, Orcan Ogetbil wrote: Again I say updates-testing! Leaving php-5.3 in testing on F-11 for a couple months will warn the users what is coming up and gives them plenty of time to adapt. If you have a large codebase two months is barely enough time to even big evaluating a move Then make it 3 months, 4 months... Leave it in testing forever if you get too many complaints. But make it available for those who want it. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Again I say updates-testing! Leaving php-5.3 in testing on F-11 for a couple months will warn the users what is coming up and gives them plenty of time to adapt. If you have a large codebase two months is barely enough time to even big evaluating a move Then make it 3 months, 4 months... Leave it in testing forever if you get too many complaints. But make it available for those who want it. They can get it from Koji or Rawhide too, can't they? Let's look at who will be looking for a new PHP. Normal Joe User won't look for it. Developers will. Developers are more likely to be able to deal with the added pain of having to build something from somewhere. But Normal Joe User can not be expected to deal with any breakages or the burden of too many updates. There are people in this world who are not blessed with super fast, limitless Internet connections. Cheers, Debarshi -- One reason that life is complex is that it has a real part and an imaginary part. -- Andrew Koenig -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote: On 03/07/2010 07:17 AM, Orcan Ogetbil wrote: Then make it 3 months, 4 months... Leave it in testing forever if you get too many complaints. But make it available for those who want it. updates-testing should not be used for this purpose because among other things you might want to push a bug fix for the previous release that is more urgent and if we are doing this we need a separate update stream So? That is not a common situation and does not happen with most packages. But you are right it does happen. Supporting a small urgent fixes repo, OR being able to have multiple versions of one package in updates-testing shouldn't be too hard. Meanwhile, I believe in that updates-testing should be extensively used for such upcoming updates by (almost) everyone. The pros are obvious. What are the cons of this model? Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/7 Orcan Ogetbil oget.fed...@gmail.com: On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote: On 03/07/2010 07:17 AM, Orcan Ogetbil wrote: Then make it 3 months, 4 months... Leave it in testing forever if you get too many complaints. But make it available for those who want it. updates-testing should not be used for this purpose because among other things you might want to push a bug fix for the previous release that is more urgent and if we are doing this we need a separate update stream So? That is not a common situation and does not happen with most packages. But you are right it does happen. Supporting a small urgent fixes repo, OR being able to have multiple versions of one package in updates-testing shouldn't be too hard. Meanwhile, I believe in that updates-testing should be extensively used for such upcoming updates by (almost) everyone. The pros are obvious. What are the cons of this model? entities must not be multiplied beyond necessity Now we got: fedora-updates fedora-updates-testing It's easy to add another repos: fedora-updates-urgent fedora-updates-really-urgent fedora-updates-not-really-urgent fedora-updates-next-year Adding additional repo _won't_ solve the problem. I only use packages from fedora-updates-testing from time to time - many regular users do the same thing. I bet that most users don't even know about this repo... Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
2010/3/6 Michał Piotrowski: 2010/3/7 Orcan Ogetbil: On Sat, Mar 6, 2010 at 8:45 PM, Rahul Sundaram wrote: On 03/07/2010 07:17 AM, Orcan Ogetbil wrote: Then make it 3 months, 4 months... Leave it in testing forever if you get too many complaints. But make it available for those who want it. updates-testing should not be used for this purpose because among other things you might want to push a bug fix for the previous release that is more urgent and if we are doing this we need a separate update stream So? That is not a common situation and does not happen with most packages. But you are right it does happen. Supporting a small urgent fixes repo, OR being able to have multiple versions of one package in updates-testing shouldn't be too hard. Meanwhile, I believe in that updates-testing should be extensively used for such upcoming updates by (almost) everyone. The pros are obvious. What are the cons of this model? entities must not be multiplied beyond necessity Now we got: fedora-updates fedora-updates-testing It's easy to add another repos: fedora-updates-urgent fedora-updates-really-urgent fedora-updates-not-really-urgent fedora-updates-next-year Adding additional repo _won't_ solve the problem. I only use packages from fedora-updates-testing from time to time - many regular users do the same thing. I bet that most users don't even know about this repo... I only gave 1 small repo suggestion, not 4. And as you obviously didn't finish reading my sentence, that is not the only solution I proposed. Read again, there is a 0 additional repo proposal too. Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 13 Alpha Go/No-Go Meeting: 2010-03-04 @ 01:00 UTC Recap
On 6 March 2010 02:50, Adam Miller wrote: On Thu, Mar 4, 2010 at 10:31 PM, Kevin Kofler wrote: Adam Williamson wrote: We have various different definitions of the Alpha, it seems. The working definition that QA / rel-eng have always worked on when deciding whether to ship it is, broadly, 'can you install it, boot it, get a network connection, and install updates'. That's what the current Alpha release criteria and validation tests aim to explicitly codify and verify. But it also fails that definition and this was ignored just because it didn't happen in the GNOME spin (which will always be the GNOME spin, not the desktop spin, but *A* desktop spin; FESCo, the Board or any other committee deciding otherwise doesn't change this, it's like deciding that apples are fruit and any other fruit can only be an orange fruit, a pear fruit etc., but not a fruit because only apples are that). :-/ [..] I apologize in advance to all those who this might offend. Kevin, please stop being such an ass all the time. I mean really, just Even though polite suggestions and pointers about discussions going away from topic are welcome, but please refrain for using inappropriate words (apologizing beforehand does not make it better). give it a rest. We get it, you *love* KDE and that's awesome but just because its not everyone's preference doesn't mean everyone is out to take KDE down. Maybe take some of this energy you spend starting Gnome vs. KDE flame wars (or trying to at least) and get more people involved in the KDE SIG. Get contributors interested and make then want to help contribute towards making the KDE experience in Fedora the best it can possibly be. [..] -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
Am Sonntag, den 07.03.2010, 01:49 +0100 schrieb Michał Piotrowski: Let's consider a situation - I'm developing a project in php 5.2. This project might work fine on php 5.3 - I don't know I didn't tested it yet. I'm depending on 5.2 version. Testing this code for a new php will take some time. Php 5.3 is considered as stable in F12 - fine for me, but IMHO should never be considered as an update for F11. Some people depend on some constant values here - php 5.2, postgres 8.3 etc. Others may be eager to test their software with 5.3, but can not spend the time to make a system update to F12. For your issue: have a look at /etc/yum.conf and exclude php from updates (instead of expecting all users of f11 to do without newer software). I know that there is a RHEL5/CentOS5 for such things, but this is pretty outdated OS for my needs. You got the point. Therefore people are using Fedora and expect to get newer software versions which may provide additional functions which may come in handy, as soon as possible. Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Welcome to Fedora docs/video/audio
Added marketing in cc (probably better place for discussion). Does it make sense to ship a small pdf (say having a title Welcome to Fedora) or if possible a video for users as an introduction to our distribution ? If yes, because it makes sense to keep it as small/simple as possible what should it target to achieve ? Points out of my head are: 1. New features 2. Availability of options for just updating system for security fixes, selected enhancements or bugfixes for some applications 3. Ways to get support/help from community - bonding 4. Feedback/reporting failures/or have suggestions etc Also, how much sense would it make to put a slide show in installer which highlights features/talk points ? Regards, -- Rakesh Pandit https://fedoraproject.org/wiki/User:Rakesh freedom, friends, features, first -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Another great update
On Sat 6 March 2010 5:54:11 pm Conrad Meyer wrote: All Fedora developers are people, too -- please remember to show some respect. Be excellent to eachother http://fedoraproject.org/wiki/Overview#Our_Community -- Ryan Rix == http://hackersramblings.wordpress.com | http://rix.si/ == signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rpms/perl-Tk-DirSelect/devel import.log, NONE, 1.1 perl-Tk-DirSelect.spec, NONE, 1.1 .cvsignore, 1.1, 1.2 sources, 1.1, 1.2
Author: hvad
Update of /cvs/pkgs/rpms/perl-Tk-DirSelect/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv27716/devel
Modified Files:
.cvsignore sources
Added Files:
import.log perl-Tk-DirSelect.spec
Log Message:
--- NEW FILE import.log ---
perl-Tk-DirSelect-1_12-2_fc12:HEAD:perl-Tk-DirSelect-1.12-2.fc12.src.rpm:1267882507
--- NEW FILE perl-Tk-DirSelect.spec ---
Name: perl-Tk-DirSelect
Version:1.12
Release:2%{?dist}
Summary:Cross-platform directory selection widget
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Tk-DirSelect/
Source0:
http://www.cpan.org/authors/id/M/MJ/MJCARMAN/Tk-DirSelect-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(Tk) = 800
BuildRequires: perl(Test::More)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
%description
This module provides a cross-platform directory selection widget. For
systems running Microsoft Windows, this includes selection of local and
mapped network drives. A context menu (right-click or Button3) allows the
creation, renaming, and deletion of directories while browsing.
%prep
%setup -q -n Tk-DirSelect-%{version}
sed -i 's/\r//' README Changes
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor
make %{?_smp_mflags}
%install
rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
%{_fixperms} $RPM_BUILD_ROOT/*
#sed -i 's/\r//' README Changes
%check
make test
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
* Fri Jan 22 2010 David Hannequin david.hanneq...@gmail.com 1.12-2
- Updated to a new upstream version.
* Fri Jan 22 2010 David Hannequin david.hanneq...@gmail.com 1.11-1
- Initial release.
Index: .cvsignore
===
RCS file: /cvs/pkgs/rpms/perl-Tk-DirSelect/devel/.cvsignore,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- .cvsignore 6 Mar 2010 05:32:31 - 1.1
+++ .cvsignore 6 Mar 2010 12:35:58 - 1.2
@@ -0,0 +1 @@
+Tk-DirSelect-1.12.tar.gz
Index: sources
===
RCS file: /cvs/pkgs/rpms/perl-Tk-DirSelect/devel/sources,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -p -r1.1 -r1.2
--- sources 6 Mar 2010 05:32:32 - 1.1
+++ sources 6 Mar 2010 12:35:58 - 1.2
@@ -0,0 +1 @@
+033967081e52398526f35c36836f0029 Tk-DirSelect-1.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 DBIx-Class-DateTime-Epoch-0.06.tar.gz uploaded to lookaside cache by cweyl
A file has been added to the lookaside cache for perl-DBIx-Class-DateTime-Epoch: 1b3df66e26f6a78f52a2bab7b56d5279 DBIx-Class-DateTime-Epoch-0.06.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-DateTime-Epoch/F-13 perl-DBIx-Class-DateTime-Epoch.spec, 1.6, 1.7 sources, 1.3, 1.4
Author: cweyl
Update of /cvs/extras/rpms/perl-DBIx-Class-DateTime-Epoch/F-13
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21365
Modified Files:
perl-DBIx-Class-DateTime-Epoch.spec sources
Log Message:
* Sat Mar 06 2010 Chris Weyl cw...@alumni.drew.edu 0.06-1
- update by Fedora::App::MaintainerTools 0.004
- PERL_INSTALL_ROOT = DESTDIR
- updating to latest GA CPAN version (0.06)
- dropped old BR on perl(Module::Build::Compat)
- dropped old BR on perl(Test::Pod::Coverage)
- altered req on perl(DBIx::Class) (0 = 0.08103)
- added a new req on perl(DBIx::Class::TimeStamp) (version 0.07)
- added a new req on perl(DateTime) (version 0)
Index: perl-DBIx-Class-DateTime-Epoch.spec
===
RCS file:
/cvs/extras/rpms/perl-DBIx-Class-DateTime-Epoch/F-13/perl-DBIx-Class-DateTime-Epoch.spec,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -r1.6 -r1.7
--- perl-DBIx-Class-DateTime-Epoch.spec 7 Dec 2009 09:52:17 - 1.6
+++ perl-DBIx-Class-DateTime-Epoch.spec 6 Mar 2010 22:08:15 - 1.7
@@ -1,29 +1,30 @@
-Name: perl-DBIx-Class-DateTime-Epoch
-Version:0.05
-Release:5%{?dist}
-# lib/DBIx/Class/DateTime/Epoch.pm - GPL+ or Artistic
-License:GPL+ or Artistic
-Group: Development/Libraries
-Summary:Automatic inflation/deflation of epoch-based DateTime objects for
DBIx::Class
-Source:
http://search.cpan.org/CPAN/authors/id/B/BR/BRICAS/DBIx-Class-DateTime-Epoch-%{version}.tar.gz
-Url:http://search.cpan.org/dist/DBIx-Class-DateTime-Epoch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildArch: noarch
-
-BuildRequires: perl(DateTime)
-BuildRequires: perl(DBIx::Class) = 0.08103
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
-BuildRequires: perl(Module::Build::Compat)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+Name: perl-DBIx-Class-DateTime-Epoch
+Summary:Automatic inflation/deflation of epoch-based DateTime objects
for DBIx::Class
+Version:0.06
+Release:1%{?dist}
+License:GPL+ or Artistic
+Group: Development/Libraries
+Source0:
http://search.cpan.org/CPAN/authors/id/B/BR/BRICAS/DBIx-Class-DateTime-Epoch-%{version}.tar.gz
+URL:http://search.cpan.org/dist/DBIx-Class-DateTime-Epoch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildArch: noarch
-Requires: perl(DBIx::Class)
-
-### auto-added brs!
-BuildRequires: perl(DBIx::Class::TimeStamp) = 0.07
+BuildRequires: perl(DateTime)
BuildRequires: perl(DBICx::TestDatabase)
+BuildRequires: perl(DBIx::Class) = 0.08103
+BuildRequires: perl(DBIx::Class::TimeStamp) = 0.07
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+
+Requires: perl(DateTime)
+Requires: perl(DBIx::Class) = 0.08103
+Requires: perl(DBIx::Class::TimeStamp) = 0.07
+
+
+%{?perl_default_filter}
+%{?perl_default_subpackage_tests}
%description
This module automatically inflates/deflates DateTime objects
@@ -43,7 +44,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} -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -62,6 +63,16 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Sat Mar 06 2010 Chris Weyl cw...@alumni.drew.edu 0.06-1
+- update by Fedora::App::MaintainerTools 0.004
+- PERL_INSTALL_ROOT = DESTDIR
+- updating to latest GA CPAN version (0.06)
+- dropped old BR on perl(Module::Build::Compat)
+- dropped old BR on perl(Test::Pod::Coverage)
+- altered req on perl(DBIx::Class) (0 = 0.08103)
+- added a new req on perl(DBIx::Class::TimeStamp) (version 0.07)
+- added a new req on perl(DateTime) (version 0)
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.05-5
- rebuild against perl 5.10.1
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBIx-Class-DateTime-Epoch/F-13/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 12 Jun 2009 20:12:34 - 1.3
+++ sources 6 Mar 2010 22:08:15 - 1.4
@@ -1 +1 @@
-091a52906a005569f0a8711a4fc5baac DBIx-Class-DateTime-Epoch-0.05.tar.gz
+1b3df66e26f6a78f52a2bab7b56d5279 DBIx-Class-DateTime-Epoch-0.06.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-DateTime-Epoch/F-12 perl-DBIx-Class-DateTime-Epoch.spec, 1.5, 1.6 sources, 1.3, 1.4
Author: cweyl
Update of /cvs/extras/rpms/perl-DBIx-Class-DateTime-Epoch/F-12
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv21732
Modified Files:
perl-DBIx-Class-DateTime-Epoch.spec sources
Log Message:
* Sat Mar 06 2010 Chris Weyl cw...@alumni.drew.edu 0.06-1
- update by Fedora::App::MaintainerTools 0.004
- PERL_INSTALL_ROOT = DESTDIR
- updating to latest GA CPAN version (0.06)
- dropped old BR on perl(Module::Build::Compat)
- dropped old BR on perl(Test::Pod::Coverage)
- altered req on perl(DBIx::Class) (0 = 0.08103)
- added a new req on perl(DBIx::Class::TimeStamp) (version 0.07)
- added a new req on perl(DateTime) (version 0)
Index: perl-DBIx-Class-DateTime-Epoch.spec
===
RCS file:
/cvs/extras/rpms/perl-DBIx-Class-DateTime-Epoch/F-12/perl-DBIx-Class-DateTime-Epoch.spec,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -p -r1.5 -r1.6
--- perl-DBIx-Class-DateTime-Epoch.spec 8 Aug 2009 19:11:04 - 1.5
+++ perl-DBIx-Class-DateTime-Epoch.spec 6 Mar 2010 22:10:20 - 1.6
@@ -1,29 +1,30 @@
-Name: perl-DBIx-Class-DateTime-Epoch
-Version:0.05
-Release:4%{?dist}
-# lib/DBIx/Class/DateTime/Epoch.pm - GPL+ or Artistic
-License:GPL+ or Artistic
-Group: Development/Libraries
-Summary:Automatic inflation/deflation of epoch-based DateTime objects for
DBIx::Class
-Source:
http://search.cpan.org/CPAN/authors/id/B/BR/BRICAS/DBIx-Class-DateTime-Epoch-%{version}.tar.gz
-Url:http://search.cpan.org/dist/DBIx-Class-DateTime-Epoch
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildArch: noarch
-
-BuildRequires: perl(DateTime)
-BuildRequires: perl(DBIx::Class) = 0.08103
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
-BuildRequires: perl(Module::Build::Compat)
-BuildRequires: perl(Test::More)
-BuildRequires: perl(Test::Pod)
-BuildRequires: perl(Test::Pod::Coverage)
+Name: perl-DBIx-Class-DateTime-Epoch
+Summary:Automatic inflation/deflation of epoch-based DateTime objects
for DBIx::Class
+Version:0.06
+Release:1%{?dist}
+License:GPL+ or Artistic
+Group: Development/Libraries
+Source0:
http://search.cpan.org/CPAN/authors/id/B/BR/BRICAS/DBIx-Class-DateTime-Epoch-%{version}.tar.gz
+URL:http://search.cpan.org/dist/DBIx-Class-DateTime-Epoch
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildArch: noarch
-Requires: perl(DBIx::Class)
-
-### auto-added brs!
-BuildRequires: perl(DBIx::Class::TimeStamp) = 0.07
+BuildRequires: perl(DateTime)
BuildRequires: perl(DBICx::TestDatabase)
+BuildRequires: perl(DBIx::Class) = 0.08103
+BuildRequires: perl(DBIx::Class::TimeStamp) = 0.07
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+
+Requires: perl(DateTime)
+Requires: perl(DBIx::Class) = 0.08103
+Requires: perl(DBIx::Class::TimeStamp) = 0.07
+
+
+%{?perl_default_filter}
+%{?perl_default_subpackage_tests}
%description
This module automatically inflates/deflates DateTime objects
@@ -43,7 +44,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} -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -62,6 +63,19 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Sat Mar 06 2010 Chris Weyl cw...@alumni.drew.edu 0.06-1
+- update by Fedora::App::MaintainerTools 0.004
+- PERL_INSTALL_ROOT = DESTDIR
+- updating to latest GA CPAN version (0.06)
+- dropped old BR on perl(Module::Build::Compat)
+- dropped old BR on perl(Test::Pod::Coverage)
+- altered req on perl(DBIx::Class) (0 = 0.08103)
+- added a new req on perl(DBIx::Class::TimeStamp) (version 0.07)
+- added a new req on perl(DateTime) (version 0)
+
+* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.05-5
+- rebuild against perl 5.10.1
+
* Sat Aug 08 2009 Chris Weyl cw...@alumni.drew.edu 0.05-4
- adjust file ownership
Index: sources
===
RCS file: /cvs/extras/rpms/perl-DBIx-Class-DateTime-Epoch/F-12/sources,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- sources 12 Jun 2009 20:12:34 - 1.3
+++ sources 6 Mar 2010 22:10:21 - 1.4
@@ -1 +1 @@
-091a52906a005569f0a8711a4fc5baac DBIx-Class-DateTime-Epoch-0.05.tar.gz
+1b3df66e26f6a78f52a2bab7b56d5279 DBIx-Class-DateTime-Epoch-0.06.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
rpms/perl-CatalystX-Component-Traits/devel perl-CatalystX-Component-Traits.spec, 1.3, 1.4
Author: cweyl
Update of /cvs/extras/rpms/perl-CatalystX-Component-Traits/devel
In directory cvs1.fedora.phx.redhat.com:/tmp/cvs-serv1551
Modified Files:
perl-CatalystX-Component-Traits.spec
Log Message:
* Sun Mar 07 2010 Chris Weyl cw...@alumni.drew.edu 0.14-3
- update by Fedora::App::MaintainerTools 0.004
- PERL_INSTALL_ROOT = DESTDIR
- dropped old BR on perl(Moose::Autobox)
- dropped old requires on perl(Moose::Autobox)
Index: perl-CatalystX-Component-Traits.spec
===
RCS file:
/cvs/extras/rpms/perl-CatalystX-Component-Traits/devel/perl-CatalystX-Component-Traits.spec,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -r1.3 -r1.4
--- perl-CatalystX-Component-Traits.spec7 Dec 2009 05:18:45 -
1.3
+++ perl-CatalystX-Component-Traits.spec7 Mar 2010 06:27:20 -
1.4
@@ -1,40 +1,35 @@
-Name: perl-CatalystX-Component-Traits
-Version:0.14
-Release:2%{?dist}
-# lib/CatalystX/Component/Traits.pm - GPL+ or Artistic
-License:GPL+ or Artistic
-Group: Development/Libraries
-Summary:Automatic Trait Loading and Resolution for
-Source:
http://search.cpan.org/CPAN/authors/id/R/RK/RKITOVER/CatalystX-Component-Traits-%{version}.tar.gz
-Url:http://search.cpan.org/dist/CatalystX-Component-Traits
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildArch: noarch
-
-BuildRequires: perl(Catalyst::Runtime) = 5.80005
-BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
-BuildRequires: perl(List::MoreUtils)
-BuildRequires: perl(Module::Pluggable) = 3.9
-BuildRequires: perl(Moose::Autobox)
-BuildRequires: perl(MooseX::Traits::Pluggable) = 0.08
-BuildRequires: perl(namespace::autoclean)
-BuildRequires: perl(Scalar::Util)
-BuildRequires: perl(Test::More) = 0.88
-BuildRequires: perl(CPAN)
-# optional tests
-BuildRequires: perl(Test::Pod)
+Name: perl-CatalystX-Component-Traits
+Summary:Automatic Trait Loading and Resolution for
+Version:0.14
+Release:3%{?dist}
+License:GPL+ or Artistic
+Group: Development/Libraries
+Source0:
http://search.cpan.org/CPAN/authors/id/R/RK/RKITOVER/CatalystX-Component-Traits-%{version}.tar.gz
+URL:http://search.cpan.org/dist/CatalystX-Component-Traits
+BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+BuildArch: noarch
+
+BuildRequires: perl(Catalyst::Runtime) = 5.80005
+BuildRequires: perl(CPAN)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.42
+BuildRequires: perl(List::MoreUtils)
+BuildRequires: perl(Module::Pluggable) = 3.9
+BuildRequires: perl(MooseX::Traits::Pluggable) = 0.08
+BuildRequires: perl(namespace::autoclean)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test::More) = 0.88
+BuildRequires: perl(Test::Pod)
-# autoreq really doesn't have a clue when it comes to Moosey bits
Requires: perl(Catalyst::Runtime) = 5.80005
-Requires: perl(Moose::Autobox)
+Requires: perl(List::MoreUtils)
Requires: perl(MooseX::Traits::Pluggable) = 0.08
+Requires: perl(namespace::autoclean)
+Requires: perl(Scalar::Util)
-%{?perl_default_filter}
-### auto-added reqs!
-Requires: perl(List::MoreUtils)
-Requires: perl(Scalar::Util)
-Requires: perl(namespace::autoclean)
+%{?perl_default_filter}
+%{?perl_default_subpackage_tests}
%description
Adds a COMPONENT method to your Catalyst component base class that
@@ -53,7 +48,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} -depth -type d -exec rmdir {} 2/dev/null ';'
@@ -72,6 +67,12 @@ rm -rf %{buildroot}
%{_mandir}/man3/*.3*
%changelog
+* Sun Mar 07 2010 Chris Weyl cw...@alumni.drew.edu 0.14-3
+- update by Fedora::App::MaintainerTools 0.004
+- PERL_INSTALL_ROOT = DESTDIR
+- dropped old BR on perl(Moose::Autobox)
+- dropped old requires on perl(Moose::Autobox)
+
* Mon Dec 7 2009 Stepan Kasal ska...@redhat.com - 0.14-2
- rebuild against perl 5.10.1
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
