Re: kernel building instructions
On 26 September 2010 09:25, Piscium grok...@gmail.com wrote: My question is this: what should be the name of the configuration file for Intel 32 bits architecture? config-x86 or config-i386 or config-i686 or one of the above followed by -generic? My custom kernel seems to be running as well as the non-custom (and a bit faster), and my customization is reflected in the installed configuration file in /boot. The answer to my question above appears to be: config-x86-generic. It would be nice if someone experienced with kernel building, and 10 minutes available, would improve the wiki page below: http://fedoraproject.org/wiki/Docs/CustomKernel#Configure_Kernel_Options Thanks. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Saturday, September 25, 2010 09:03:08 pm Kevin Fenzi wrote: On Thu, 23 Sep 2010 16:58:39 +0200 Jaroslav Reznik jrez...@redhat.com wrote: Not a very latest thing but more like - more useful thing. Because some useful user experience changes could lead to better user experience even changing slightly the old one. It's not easy to catch this in policy. I like the idea, I understand why we want it - I want it too, why we need it, it's more relaxed than the first proposals leading practically to frozen, dead and unmaintained releases. But still there should be more space for packager's decision and of course upstream - upstream releases for some reason. Sure sometimes things change for the better... a new UI is nicer than the old one. The thing is that most people don't want that to happen on some random day in the middle of a stable release. This would cause them to stop doing what they wanted to do to learn the new UI. Much better when it's in the new Fedora release where they realize that they need to learn how the new version works before using it. It's not some random day - it's when you actually accept an update! It's not easy to estimate impact of update - but banning completely is not a solution neither. Also this stability proposal has to be coupled with a new release scheme - not just update policy but also release schedules, what we are going to call release, how often (9 months? branch every 6 - we we talking with Jesse a few minutes ago), how big changes we want in a new release etc... I'm not sure it's going to work without deeper changes here too. Feel free to put together a detailed proposal on a new release cycle and we can take a look. I've often thought a 9month cycle (18 or 19 months supported) would be nice and give us more time, but then we are misaligned with a number of projects upstream that are on a 6 month cycle, and also, we don't release at the same time(s) each year, resulting in hitting holidays or the like. :( Hmm, release cycles of upstream projects are problem. You're right. I'm still more for my slow-down proposal (not yet proposed - I just lost all ideals and sense of life - as it looked like NO is general conclusion. Now I feel again chance that someone will listen ;-). R. I don't know a solution, but if you come up with one, please do let me know. ;) There's probably no right solution - I just don't want to see as inflexible and bind by our own rules - open source is living body. I'm a fan of making Fedora better but I'm just not sure this is enough and it needs a lot more - as I said - different release scheme, make underlaying services more bullet proof (upstream task). Last time my Fedora didn't boot because of kdump (it was rebuilding, rebuilding and rebuilding initrd forever) - just banning updates does not help, it was easy for me to disable kdump service through run level 1, not easy for average user (and I'm not talking about basic user, avarage). Jaroslav kevin -- Jaroslav Řezník jrez...@redhat.com Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100927 changes
Compose started at Mon Sep 27 08:15:36 UTC 2010 Broken deps for x86_64 -- ImageMagick-6.6.4.1-14.fc15.i686 requires libgs.so.8 ImageMagick-6.6.4.1-14.fc15.x86_64 requires libgs.so.8()(64bit) almanah-0.7.3-3.fc14.x86_64 requires libedataserverui-1.2.so.10()(64bit) antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 claws-mail-plugins-geolocation-3.7.6-5.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gst-devel-1.2.0-1.fc15.i686 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gst-devel-1.2.0-1.fc15.x86_64 requires pkgconfig(clutter-1.0) 0:1.3.0 clutter-gtkmm-0.9.5-1.fc14.i686 requires libclutter-gtk-0.10.so.0 clutter-gtkmm-0.9.5-1.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) clutter-gtkmm-devel-0.9.5-1.fc14.i686 requires pkgconfig(clutter-gtk-0.10) = 0:0.10.2 clutter-gtkmm-devel-0.9.5-1.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) = 0:0.10.2 emerillon-0.1.2-7.fc14.x86_64 requires librest-0.6.so.0()(64bit) emerillon-0.1.2-7.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgtkjava-2.8.so frysk-devel-0.4-26.fc14.i386 requires libglibjava-0.2.so frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-devel-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libglibjava-0.2.so()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgtkjava-2.8.so()(64bit) 1:gnome-games-extra-2.31.91.1-1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-media.so.1()(64bit) gnome-python2-brasero-2.31.1-5.fc14.x86_64 requires libbrasero-burn.so.1()(64bit) gnome-python2-totem-2.31.1-5.fc14.x86_64 requires libgnome-media-profiles.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) hornsey-1.5.2-0.3.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libchamplain-gtk-0.6.1-4.fc14.i686 requires libclutter-gtk-0.10.so.0 libchamplain-gtk-0.6.1-4.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) libchamplain-gtk-devel-0.6.1-4.fc14.i686 requires pkgconfig(clutter-gtk-0.10) libchamplain-gtk-devel-0.6.1-4.fc14.x86_64 requires pkgconfig(clutter-gtk-0.10) 1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires libedata-book-1.2.so.3()(64bit) 1:libopensync-plugin-evolution2-0.22-6.fc14.x86_64 requires libedata-cal-1.2.so.8()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-1.2.so.18()(64bit) mail-notification-evolution-plugin-5.4-22.fc14.x86_64 requires libcamel-provider-1.2.so.18()(64bit) meego-panel-devices-0.2.4-2.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) meego-panel-zones-0.2.0-0.1.fc15.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) moblin-app-installer-0.4.0-0.9.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libsocialweb-client.so.1()(64bit) moblin-panel-status-0.1.21-5.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc pyclutter-gtk-0.10.0-2.fc14.x86_64 requires libclutter-gtk-0.10.so.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc15.noarch requires spacewalk-backend-libs = 0:0.8.28 totem-2.90.5-5.fc15.i686 requires libpeasui-1.0.so.0 totem-2.90.5-5.fc15.x86_64 requires libpeasui-1.0.so.0()(64bit) tracker-evolution-plugin-0.8.17-1.fc15.x86_64 requires libcamel-1.2.so.18()(64bit) tracker-evolution-plugin-0.8.17-1.fc15.x86_64 requires libcamel-provider-1.2.so.18()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- ImageMagick-6.6.4.1-14.fc15.i686 requires libgs.so.8 almanah-0.7.3-3.fc14.i686 requires libedataserverui-1.2.so.10 antlr3-python-3.1.2-7.fc14.noarch requires python(abi) =
poppler update to 0.15.0 (0.16 alpha)
Hi all, I plan to update update poppler in rawhide (Fedora 15) to new development version 0.15 next week (at Monday, October 4th). Changes against 0.14.x are: core: * Remove exception support * Improve creation of Annotations * Fix failure to parse PDF with damaged internal structure. (Bugs #29189 #3870) * Add a way to access the raw text of a page * Speed improvements when reading multiple characters from a given Stream * Speed improvements in the Splash backend * Speed improvement in gray color space calculations * Speed improvement in ICC color space calculations * Speed improvement when reading some fonts * Make GBool a bool instead of an int glib: * Add GObject introspection support * Improve creation of Annotations * Add a way to get the coordinates of each character of a page * Add a way to get the page label * Documentation improvements * Support password protected documents in the demo * Support for selection in the demo * Support for adding annotationss in the demo * Misc improvements in the internals qt4: * Add a way to access the raw text of a page * Recognize Print as named action * Documentation improvements build system: * Add option for autogen.sh to skip configure * Nicer autogen.sh output * Improvements when build the glib frontend with CMake utils: * pdftohtml: Use splash instead of external gs invocation to render the background * pdftohtml: Let the user specify the resolution of the background. (Bug #29551) cpp: * Add a way to access the raw text of a page + 2 soname bumps in libpoppler.so.* and libpoppler.glib.so.*. Please check whether your package builds against this new version of poppler correctly if you maintain a package which requires it. The new version has been pushed to git already but not built yet. Regards Marek ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora 14 on System Z alive and kicking!
Hi everyone! The Fedora s390x team[1] is happy to announce the first installable Fedora on IBM System Z (aka s390x) since Fedora 6! It's been a long time in the making, but after several Fedora releases since we started getting everything up into shape again we've finally reached a point where we can provide an installable version of Fedora on IBM System Z again. As it's not a final release yet and we still need to have a few minor workarounds in the installer image the location isn't yet in the typical release directory for secondary archs. We expect this to be a thing of the past once we get that last few fixes upstream and the composes running in a consistent and permanent fashion (real soon now!!!). The documentation has of course also been updated and a whole section has been added in the README on how to install your own release (not just running a hercules image as with our Fedora 11 preview version). Hercules images and instructions on how to run that or how to install it yourself can be downloaded from http://secondary.fedoraproject.org/pub/alt/spins/S390/ Individual packages are available at http://s390.koji.fedoraproject.org/mash/rawhide/s390x/os/ More info will be added in the next few days at https://fedoraproject.org/wiki/Architectures/s390x If you're interested, please join our mailing list at https://admin.fedoraproject.org/mailman/listinfo/fedora-s390x or our IRC channel #fedora-s390x on freenode.net Thanks regards, Phil [1] List of current team: * Karsten Hopp Secondary Arch Maintainer (nickname Kick_ in #fedora-s390x on IRC) * Dan Horák * Dennis Gilmore * Brad Hinson * Justin Payne (nickname kurgan in #fedora-s390x on IRC) * Phil Knirsch * David Cantrell (interest in anaconda support for s390) -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 on System Z alive and kicking!
Now plz send me a Z series and I'll take care about the updates :-P -of Phil Knirsch pknir...@redhat.com schrieb: Hi everyone! The Fedora s390x team[1] is happy to announce the first installable Fedora on IBM System Z (aka s390x) since Fedora 6! It's been a long time in the making, but after several Fedora releases since we started getting everything up into shape again we've finally reached a point where we can provide an installable version of Fedora on IBM System Z again. As it's not a final release yet and we still need to have a few minor workarounds in the installer image the location isn't yet in the typical release directory for secondary archs. We expect this to be a thing of the past once we get that last few fixes upstream and the composes running in a consistent and permanent fashion (real soon now!!!). The documentation has of course also been updated and a whole section has been added in the README on how to install your own release (not just running a hercules image as with our Fedora 11 preview version). Hercules images and instructions on how to run that or how to install it yourself can be downloaded from http://secondary.fedoraproject.org/pub/alt/spins/S390/ Individual packages are available at http://s390.koji.fedoraproject.org/mash/rawhide/s390x/os/ More info will be added in the next few days at https://fedoraproject.org/wiki/Architectures/s390x If you're interested, please join our mailing list at https://admin.fedoraproject.org/mailman/listinfo/fedora-s390x or our IRC channel #fedora-s390x on freenode.net Thanks regards, Phil [1] List of current team: * Karsten Hopp Secondary Arch Maintainer (nickname Kick_ in #fedora-s390x on IRC) * Dan Horák * Dennis Gilmore * Brad Hinson * Justin Payne (nickname kurgan in #fedora-s390x on IRC) * Phil Knirsch * David Cantrell (interest in anaconda support for s390) -- Philipp Knirsch | Tel.: +49-711-96437-470 Supervisor Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. -- 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
Upcoming Fedora 14 Tasks
Start End Name Tue 28-Sep Tue 28-Sep Beta Release Public Availability Fri 01-Oct Fri 01-Oct Final Blocker Meeting (f14blocker) #2 Fri 08-Oct Fri 08-Oct Final Blocker Meeting (f14blocker) #3 Mon 11-Oct Mon 11-Oct Submit Installer Builds for Final TC Compose Mon 11-Oct Fri 15-Oct Daily Review Notification of Open Final Blocker Bugs -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Fedora 14 on System Z alive and kicking!
2010/9/27 Phil Knirsch pknir...@redhat.com: Hi everyone! The Fedora s390x team[1] is happy to announce the first installable Fedora on IBM System Z (aka s390x) since Fedora 6! Awesome! /me still hopes that he'll see Fedora-PPC for F-14 :) -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, 2010-09-25 at 15:13 +0200, Till Maas wrote: On Thu, Sep 23, 2010 at 09:48:34AM -0400, Adam Jackson wrote: Say you ship with 50 bugs in a package. As you update it through the lifetime of a release, that number should decrease more or less monotonically. The bugs that take longest to fix are presumably the hardest ones to fix, and thus the ones that either require significant rewrites (and become out of scope for an update release), or won't get fixed at all. So it's really just describing what _happens_ naturally if you don't rebase all the time. The bug number will probably decrease, but this does not meant that the lifetime of a release is long enough to fix them all or even to find them all. E.g. if 5 bugs are fixed every month, you will still have the same rate of updates for 10 months, unless you just delay updates even if the bugs could already be fixed. And also usually not all bugs are known when at the beginning of the release. Those are things that could happen. All my experience says that's not what actually happens. The update rate graphs lmacken does every once in a while certainly look like the update rate _does_ slow. - ajax signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100927 changes
Compose started at Mon Sep 27 13:15:27 UTC 2010 Broken deps for x86_64 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.x86_64 requires libedata-book-1.2.so.2()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-1.2.so.17()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libgtkhtml-editor.so.0()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libebook-1.2.so.9()(64bit) evolution-couchdb-0.4.92-1.fc14.x86_64 requires libcamel-provider-1.2.so.17()(64bit) evolution-sharp-0.21.1-9.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) frysk-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) frysk-gnome-0.4-26.fc14.x86_64 requires libgcj.so.10()(64bit) gnome-python2-evolution-2.31.1-5.fc14.x86_64 requires libcamel-1.2.so.19()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-gtk-0.4.so.0()(64bit) gpx-viewer-0.1.2-2.fc14.x86_64 requires libchamplain-0.4.so.0()(64bit) intellij-idea-9.0.1.94.399-11.fc14.x86_64 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libglade-java-2.12.5-12.fc12.x86_64 requires libgcj.so.10()(64bit) libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.x86_64 requires libgcj.so.10()(64bit) libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.x86_64 requires libgcj.so.10()(64bit) matahari-0.0.5-1.fc14.x86_64 requires libqmf.so.1()(64bit) mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickWand.so.3()(64bit) php-pecl-imagick-3.0.0-7.fc14.x86_64 requires libMagickCore.so.3()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_thread-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_filesystem-mt.so.1.41.0()(64bit) plee-the-bear-0.4.1-5.fc14.x86_64 requires libboost_system-mt.so.1.41.0()(64bit) qtgpsc-0.2.3-6.fc12.x86_64 requires libgps.so.18()(64bit) spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0 valide-0.6.1-0.22.20103003svn511.fc14.x86_64 requires libvala.so.0()(64bit) viking-0.9.91-3.fc13.x86_64 requires libgps.so.18()(64bit) wfut-1.1.0-8.fc12.x86_64 requires libgcj.so.10()(64bit) Broken deps for i386 -- antlr3-python-3.1.2-7.fc14.noarch requires python(abi) = 0:2.6 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-provider-1.2.so.17 evolution-couchdb-0.4.92-1.fc14.i686 requires libebook-1.2.so.9 evolution-couchdb-0.4.92-1.fc14.i686 requires libgtkhtml-editor.so.0 evolution-couchdb-0.4.92-1.fc14.i686 requires libedata-book-1.2.so.2 evolution-couchdb-0.4.92-1.fc14.i686 requires libcamel-1.2.so.17 evolution-sharp-0.21.1-9.fc14.i686 requires libcamel-1.2.so.19 frysk-0.4-26.fc14.i386 requires libgcj.so.10 frysk-devel-0.4-26.fc14.i386 requires libgcj.so.10 frysk-gnome-0.4-26.fc14.i386 requires libgcj.so.10 gnome-python2-evolution-2.31.1-5.fc14.i686 requires libcamel-1.2.so.19 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0 gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0 intellij-idea-9.0.1.94.399-11.fc14.i686 requires jna-examples libglade-java-2.12.5-12.fc12.i686 requires libgcj.so.10 libgnome-java-2.12.4-12.fc12.i686 requires libgcj.so.10 libvte-java-0.12.1-15.fc12.i686 requires libgcj.so.10 matahari-0.0.5-1.fc14.i686 requires libqmf.so.1 mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires mingw32(libpng-3.dll) ovirt-server-0.100-4.fc12.noarch requires qpidd ovirt-server-0.100-4.fc12.noarch requires qpidc php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickCore.so.3 php-pecl-imagick-3.0.0-7.fc14.i686 requires libMagickWand.so.3 plee-the-bear-0.4.1-5.fc14.i386 requires libboost_filesystem-mt.so.1.41.0 plee-the-bear-0.4.1-5.fc14.i386 requires libboost_system-mt.so.1.41.0 plee-the-bear-0.4.1-5.fc14.i386 requires libboost_thread-mt.so.1.41.0 qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18 spacewalk-certs-tools-1.1.1-2.1.fc14.noarch requires spacewalk-backend-libs = 0:0.8.28 valide-0.6.1-0.22.20103003svn511.fc14.i686 requires libvala.so.0
Re: Linux and application installing - screen shots of UI mock up
Ok, I made some screen shots. It's a bit easier to understand if you see it actually working. They should still give you a idea. Looking at the PackageDB tags, filtering for the Office and Qt tags: http://fedorapeople.org/~ffesti/screenshots/PackageDBTags.gif Filtering for the GNOME menu tag and looking at the results found with the Audio tag. http://fedorapeople.org/~ffesti/screenshots/MenuTags.gif Still filtering for GNOME but looking at the stripped down Applications menu, showing the results in Applications-Games-Board: http://fedorapeople.org/~ffesti/screenshots/Applications.gif Searching for circuit and look at the results found in the comps groups - wondering why we found some games: http://fedorapeople.org/~ffesti/screenshots/Search.gif Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
docbook and glibc breakage?
All three of my newly released GNOME 2.32.0 projects failed to build on koji (f14) today: http://koji.fedoraproject.org/koji/getfile?taskID=2491737name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491754name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491800name=build.log I've been told it's something to do with the way glibc decides to interpret posix rules for character classes, which seems to have broken grep. Can we revert the new glibc from the buildsystem please, until the breakage is fixed upstream. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
What does matter to Fedora is having an updates policy that is designed to minimize disruption to users during a release is pointless if a significant part of Fedora - KDE - is going to be allowed to ignore the updates policy and deliberately introduce visible to the user changes in the middle of a release. Most of us KDE users want deliberate visible changes to the user. That's the point in having the latest version. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
Jaroslav Reznik (jrez...@redhat.com) said: It's not some random day - it's when you actually accept an update! It's not easy to estimate impact of update - but banning completely is not a solution neither. We do not give nearly enough information in our updates for the user to make any informed decision here. Just tagging it as 'enhancement' isn't enough. So, it most of the time does boil down to: 1) they accept updates in general, and they get it on some random day 2) they wonder, think updates may change things. Therefore updates are scary, and should be avoided by the user. Neither of these are great. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, Sep 25, 2010 at 22:26, Brandon Lozza bran...@pwnage.ca wrote: I can't tell people Fedora is the best if it's not carrying the latest upstream KDE, its just not possible. I'm constantly recruiting new users. I'm in regular contact with the team of people who run Techrights. ... lots cut out ... Brandon, I am not trying to pick a fight, but am trying to point out some communication problems with your emails. The way it reads is: Fedora should revolve around my SIG. And if it doesn't then that makes Fedora crap. This pretty much makes the whole conversation binary: 1 revolve around me, or 0 head towards crap. Which pretty much puts this into a collision course in the same way that people wanting us to name it Fedora GNU/Linux go: It ain't gonna happen and the more you keep it binary the less likely it will happen in the future. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F14 Final Wiki Freeze
Monday, October 4, is the wiki freeze for the GA release notes. If there is something you want to see in the release notes now is your last chance. The release notes draft content can be found at https://fedoraproject.org/wiki/Documentation_Beats This page links to a wiki page for each area in the release notes. Simply add your content to one of these pages. It will be edited so there is no need to be concerned about getting elegant prose. Just getting the fact down will be a help. Thanks --McD -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide x86_64: WiFi completely hosed, ditto GDM
Horst H. von Brand vonbr...@inf.utfsm.cl wrote: As of yesterday there simply is no way to get WiFi (iwlagn here) to work. Restarting NetworkManager, avahi-daemon, udevd, dbus has no effect. Restrarting nm-applet does nothing, no response to iwconfig ow iw. The configuration for the wired network (set up statically for work) doesn't work either, but connecting at home with DHCP does work. GDM crashed on boot yesterday, luckily I've got XDM (and XFCE) installed here. Tried again yesterday, what is totally hosed is NetworkManager under XFCE, on Gnome it does work fine https://bugzilla.redhat.com/show_bug.cgi?id=637847 -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Rawhide x86_64: WiFi completely hosed, ditto GDM
On Mon, 27 Sep 2010 13:30:31 -0400 Horst H. von Brand vonbr...@inf.utfsm.cl wrote: Horst H. von Brand vonbr...@inf.utfsm.cl wrote: As of yesterday there simply is no way to get WiFi (iwlagn here) to work. Restarting NetworkManager, avahi-daemon, udevd, dbus has no effect. Restrarting nm-applet does nothing, no response to iwconfig ow iw. The configuration for the wired network (set up statically for work) doesn't work either, but connecting at home with DHCP does work. GDM crashed on boot yesterday, luckily I've got XDM (and XFCE) installed here. Tried again yesterday, what is totally hosed is NetworkManager under XFCE, on Gnome it does work fine https://bugzilla.redhat.com/show_bug.cgi?id=637847 does 'ck-list-sessions' show a valid local consolekit session? You are using xdm? really? Try lxdm. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Sat, 25 Sep 2010 22:26:46 -0400 Brandon Lozza bran...@pwnage.ca wrote: I can't tell people Fedora is the best if it's not carrying the latest upstream KDE, its just not possible. I'm constantly recruiting new users. I'm in regular contact with the team of people who run Techrights. I would personally suggest a different marketing strategy. Perhaps it would be better to: a) Note that Fedora has an active and welcoming KDE SIG. b) The Fedora KDE sig works with upstream on bugs to improve KDE for everyone. c) Fedora KDE is easy to try out with a live media or by groupinstalling kde. ...snip... This makes Fedora BETTER than the rest. If we delegate the latest KDE to backports like everyone else, how does that make Fedora better? And we do want to be better than everyone else if we want to compete with Apple and Microsoft. I respectfully disagree, but you're entitled to your opinion. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Mon, 27 Sep 2010 10:19:51 +0200 Jaroslav Reznik jrez...@redhat.com wrote: It's not some random day - it's when you actually accept an update! It's not easy to estimate impact of update - but banning completely is not a solution neither. Well, most people either: a) apply all updates as they come and hope for the best or that they can fix issues or deal with them as they show up. or b) are afraid of updates and only apply them rarely when they need something from them or have a lot of time to deal with fallout. I would like it to be: c) apply updates often and are confident that nothing will blow up or change so they need to re-learn something, and they get all the security updates in a timely manner. Hmm, release cycles of upstream projects are problem. You're right. I'm still more for my slow-down proposal (not yet proposed - I just lost all ideals and sense of life - as it looked like NO is general conclusion. Now I feel again chance that someone will listen ;-). Yeah, and it's up to our maintainers to talk to their upstreams and convince them to try doing a better job. ;) There's probably no right solution - I just don't want to see as inflexible and bind by our own rules - open source is living body. I'm a fan of making Fedora better but I'm just not sure this is enough and it needs a lot more Well, we have a base set of rules and a process to request exceptions for the corner cases. ;) - as I said - different release scheme, make underlaying services more bullet proof (upstream task). Last time my Fedora didn't boot because of kdump (it was rebuilding, rebuilding and rebuilding initrd forever) - just banning updates does not help, it was easy for me to disable kdump service through run level 1, not easy for average user (and I'm not talking about basic user, avarage). If we try and come up with a master complicated change plan we will never do anything. I maintain we can put this updates policy into effect NOW (or soon) and gain from it right away. ;) If we need to adjust more (either way) we should not be afraid to do so, but we shouldn't just sit here and keep talking either. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
x86_64 as Fedora's primary platform
The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, 2010-09-27 at 13:48 -0400, Gregory Maxwell wrote: The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. until i686 is uncommon (which is still not yet) I think we should keep the default i686. -sv -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 13:48, Gregory Maxwell gmaxw...@gmail.com wrote: The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? Well while many people have x86_64 capable hardware, 66% of the systems have less than 2GB of ram installed on them. The gain of extra registers is taken over by the amount of extra memory used. So I am not sure pushing 64 bit will gain much beyond why am I using so much memory now? messages. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 09/27/2010 06:53 PM, seth vidal wrote: i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. until i686 is uncommon (which is still not yet) I think we should keep the default i686. Most (if not all) Atom-based netbook are i686. -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Orphaning packages
[1] attica -- Implementation of the Open Collaboration Services API [2] automoc -- Automatic moc for Qt 4 [3] bip -- IRC Bouncer [4] kbluetooth -- The KDE Bluetooth Framework [5] kdebluetooth -- The KDE Bluetooth Framework [6] shared-desktop-ontologies -- Shared ontologies needed for semantic environments Lorenzo _ [1]: https://admin.fedoraproject.org/pkgdb/acls/name/attica [2]: https://admin.fedoraproject.org/pkgdb/acls/name/automoc [3]: https://admin.fedoraproject.org/pkgdb/acls/name/bip [4]: https://admin.fedoraproject.org/pkgdb/acls/name/kbluetooth [5]: https://admin.fedoraproject.org/pkgdb/acls/name/kdebluetooth [6]: https://admin.fedoraproject.org/pkgdb/acls/name/shared-desktop-ontologies -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
2010/9/27 Athmane Madjoudj athma...@gmail.com: On 09/27/2010 06:53 PM, seth vidal wrote: i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. until i686 is uncommon (which is still not yet) I think we should keep the default i686. Most (if not all) Atom-based netbook are i686. AFAICS only old single core Diamondville http://en.wikipedia.org/wiki/List_of_Intel_Atom_microprocessors#Single-Core_Netbook_processors But I think it is quite popular CPU Regards, Michal -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Orphaning packages
On Mon, Sep 27, 2010 at 08:15:46PM +0200, Lorenzo Villani wrote: [1] attica -- Implementation of the Open Collaboration Services API [2] automoc -- Automatic moc for Qt 4 [3] bip -- IRC Bouncer Adopted bip. [4] kbluetooth -- The KDE Bluetooth Framework [5] kdebluetooth -- The KDE Bluetooth Framework [6] shared-desktop-ontologies -- Shared ontologies needed for semantic environments -- Brian C. Lane / Anaconda Team Port Orchard, WA (PST8PDT) pgp8FMeP8HO4f.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
All three of my newly released GNOME 2.32.0 projects failed to build on koji (f14) today: http://koji.fedoraproject.org/koji/getfile?taskID=2491737name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491754name=build.log http://koji.fedoraproject.org/koji/getfile?taskID=2491800name=build.log I've been told it's something to do with the way glibc decides to interpret posix rules for character classes, which seems to have broken grep. Can we revert the new glibc from the buildsystem please, until the breakage is fixed upstream. Thanks. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel AFAIK the following message from build log indicates incorrect regular expressions in docbook-utils: grep: character class syntax is [[:space:]], not [:space:] The character class must be inside bracketed expression, thus double brackets, please see man grep. The new grep-2.7 checks for this common fault: grep now diagnoses (and fails with exit status 2) commonly mistyped regular expression like [:space:], [:digit:], etc. Before, those were silently interpreted as [ac:eps] and [dgit:] respectively. Virtually all who make that class of mistake should have used [[:space:]] or [[:digit:]]. This new behavior is disabled when the POSIXLY_CORRECT environment variable is set. regards Jaroslav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 1:58 PM, Stephen John Smoogen smo...@gmail.com wrote: On Mon, Sep 27, 2010 at 13:48, Gregory Maxwell gmaxw...@gmail.com wrote: The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? Well while many people have x86_64 capable hardware, 66% of the systems have less than 2GB of ram installed on them. The gain of extra registers is taken over by the amount of extra memory used. So I am not sure pushing 64 bit will gain much beyond why am I using so much memory now? messages. I agree that systems which are very short on memory will be happier with i386 but I don't think 2GBytes is at all a reasonable cut-off. None of the x86_64 desktops I have access to are currently using more than 1Gbyte (ignoring cache, of course). Only something like 11% of systems have less than 512MBytes, roughly 1/3rd with less than 1Gbyte. If you're not swapping x86_64 bringing increased performance is easily demonstrated, and has been previously demonstrated here... if there is any doubt on this point I'd be glad to run some more benchmarks to demonstrate it. E.g. On a random 720p video file (http://xiph.org/video/vid1.shtml) Theora decode is over 20% faster with x86_64 compared to i686 on the same hardware (X3360), even though libtheora can detect and use SSE2 at runtime. I admit that this is probably one of the bigger differences— the point is that the improvement is can be very non-trivial on CPU bound code that actually matters to users. On Mon, Sep 27, 2010 at 1:53 PM, seth vidal skvi...@fedoraproject.org wrote: i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. until i686 is uncommon (which is still not yet) I think we should keep the default i686. I find it somewhat incomprehensible that Fedora has chosen to _completely exclude_ pre-P6 cpus and came fairly close to also excluding x86 systems without SSE2 (which are still being mass produced)— but Fedora won't promote x86_64 as a leading option when it only constitutes a majority of the target system. What is the thinking here? Is it really better to make Fedora not run at all on part of the installed base in order to force-fit the i686 builds as high performance options, simply because defaulting to the real high performance option will make the install process a little trickier for users on netbooks? On Mon, Sep 27, 2010 at 1:59 PM, Athmane Madjoudj athma...@gmail.com wrote: Most (if not all) Atom-based netbook are i686. Indeed, the netbooks have special requirements. The in-order atom CPUs alone benefit from fairly different compiler scheduling which is less than ideal for the extensively out of order cpus used everywhere else. The netbooks are also special in a number of other ways... I doubt there are many desktops out there with 1024x600 screens. Since the needs of netbook users are so specialized, why aren't they being directed to a netbook specific spin? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Nautilus still no go in rawhide
On Sun, Sep 26, 2010 at 9:45 AM, darrell pfeifer darrel...@gmail.com wrote: On Sun, Sep 26, 2010 at 09:30, Tom London seli...@gmail.com wrote: On Sat, Sep 25, 2010 at 8:21 PM, darrell pfeifer darrel...@gmail.com wrote: On Sat, Sep 25, 2010 at 11:55, Owen Taylor otay...@redhat.com wrote: On Sat, 2010-09-25 at 14:04 -0400, Owen Taylor wrote: (nautilus:11408): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed Segmentation fault (core dumped) There also seem to be problems with nautilus from GTK+ ABI changes - I see various warnings along the lines of: (nautilus:27082): GLib-GObject-WARNING **: specified class size for type `EvPropertiesView' is smaller than the parent type's `GtkVBox' class size These indicate a definite need for rebuild, so I'll kick one off now, and maybe things will be better after that finishes. It's certainly not worth worrying about anything related to Nautilus until it's rebuild. The newer version still dies. It seemed to work for a while but segfaults again. Also, sftp doesn't work any more. Interestingly enough, it doesn't segfault under KDE. darrell -- Does this sound like your segfaults: https://bugzilla.redhat.com/show_bug.cgi?id=636543 I'm guessing that is some change in the gtk3 interface... I haven't run a stack trace on mine, so I can't be sure. Your guess might be accurate though. I also notice that chrome has been segfaulting with annoying frequency which is strange because it has been very stable for me. darrell -- Interesting. I just locally patched gtk3 (as described here: https://bugzilla.redhat.com/show_bug.cgi?id=636543), and now 'automounting' appears to be working as usual: the nice nautilus window with the device's root directory opens as expected. I'm running: nautilus-2.90.1-5.gitf3bbee7.fc15.x86_64 gtk3-2.90.7-2.local.fc15.x86_64 --- this is the 'patched' gtk3. I don't know if this is the 'right' patch, but this appears to indicate (at least part of) a problem. tom -- Tom London -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 27/09/10 20:12, Gregory Maxwell wrote: snip If you're not swapping x86_64 bringing increased performance is easily demonstrated, and has been previously demonstrated here... if there is any doubt on this point I'd be glad to run some more benchmarks to demonstrate it. For me inept brain. You mean no swap partition? snip -- Regards, Frank Murphy UTF_8 Encoded Friend of Fedora -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
On 27 September 2010 19:58, Jaroslav Skarvada jskar...@redhat.com wrote: The character class must be inside bracketed expression, thus double brackets, please see man grep. The new grep-2.7 checks for this common fault: Right, but you could argue it's a regression as the behavior changed. Could somebody please fix docbook-utils, otherwise all the GNOME koji builds are going to fail. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 15:12, Gregory Maxwell gmaxw...@gmail.com wrote: On Mon, Sep 27, 2010 at 1:58 PM, Stephen John Smoogen smo...@gmail.com wrote: On Mon, Sep 27, 2010 at 13:48, Gregory Maxwell gmaxw...@gmail.com wrote: The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? Well while many people have x86_64 capable hardware, 66% of the systems have less than 2GB of ram installed on them. The gain of extra registers is taken over by the amount of extra memory used. So I am not sure pushing 64 bit will gain much beyond why am I using so much memory now? messages. I agree that systems which are very short on memory will be happier with i386 but I don't think 2GBytes is at all a reasonable cut-off. None of the x86_64 desktops I have access to are currently using more than 1Gbyte (ignoring cache, of course). Only something like 11% of systems have less than 512MBytes, roughly 1/3rd with less than 1Gbyte. My laptop went into swap after about 4 hours of work from firefox, thunderbird, and xchat. At 4 GB I find it pretty stable. On a longer state. Redesigning that page always causes a painful long list of arguments as everyone wants to be on the top or listed. PPC, KDE, LXDE, and s390 all come out of the woodwork and want a big link on top (or lets randomize it to make it even!). So after the last bikeshedding and my distro is bigger and larger than yours talk.. it was decided to go with one that worked best on the largest install base. -- Stephen J Smoogen. “The core skill of innovators is error recovery, not failure avoidance.” Randy Nelson, President of Pixar University. We have a strategic plan. It's called doing things. — Herb Kelleher, founder Southwest Airlines -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
Richard Hughes hughsi...@gmail.com wrote: On 27 September 2010 19:58, Jaroslav Skarvada jskar...@redhat.com wrote: The character class must be inside bracketed expression, thus double brackets, please see man grep. The new grep-2.7 checks for this common fault: Right, but you could argue it's a regression as the behavior changed. Could somebody please fix docbook-utils, otherwise all the GNOME koji builds are going to fail. Rawhide is acceptable to change like that, particularly this early in the f15 cycle. -- Sent from my Android phone. Please excuse my brevity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, 27 Sep 2010 19:53:09 +0200, seth vidal wrote: On Mon, 2010-09-27 at 13:48 -0400, Gregory Maxwell wrote: When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. F14+ livecd-tools have now /usr/bin/mkbiarch for live images automatically choosing x86_64/i686. I was told it is too late for F14 biarch spin but for F15+ that one should be the best default. (With all the movie downloads around please do not reply wrt file size.) Regards, Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[perl-Test-Unit-Runner-Xml/el6/master: 5/5] Merge branch 'master' into el6
commit 9fe003849d49c84494ea75baf1dbac037cb0ad2d Merge: d170ecc 8274a33 Author: Xavier Bachelot xav...@bachelot.org Date: Mon Sep 27 21:55:04 2010 +0200 Merge branch 'master' into el6 perl-Test-Unit-Runner-Xml.spec |8 +++- 1 files changed, 7 insertions(+), 1 deletions(-) --- -- 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: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 21:50:21 +0200, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Mon, 27 Sep 2010 19:53:09 +0200, seth vidal wrote: On Mon, 2010-09-27 at 13:48 -0400, Gregory Maxwell wrote: When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? i686 will run on x86_64 and i686 machines and on the overwhelming majority of hw someone will happen to have. x86_64 will not. F14+ livecd-tools have now /usr/bin/mkbiarch for live images automatically choosing x86_64/i686. I was told it is too late for F14 biarch spin but for F15+ that one should be the best default. (With all the movie downloads around please do not reply wrt file size.) It still matters whether or not stuff fits on target media. The number of published spins might also change with F15. Spins SIG as it has been designed isn't working and needs to change. What that change will be hasn't been worked out yet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 3:26 PM, Frank Murphy frankl...@gmail.com wrote: On 27/09/10 20:12, Gregory Maxwell wrote: snip If you're not swapping x86_64 bringing increased performance is easily demonstrated, and has been previously demonstrated here... if there is any doubt on this point I'd be glad to run some more benchmarks to demonstrate it. For me inept brain. You mean no swap partition? Ha. No. I mean so long as your working set is smaller than the amount of physical ram. Or in other words so long as your not frequently swapping things out to make room, e.g. the swap in/out counters in vmstat. On Mon, Sep 27, 2010 at 3:34 PM, Stephen John Smoogen smo...@gmail.com wrote: My laptop went into swap after about 4 hours of work from firefox, thunderbird, and xchat. At 4 GB I find it pretty stable. It's not too difficult to drive firefox into using more than 3Gbytes of _virtual memory_, with the actual in use memory much smaller. On i386 this inevitably results in a crash, while on x86_64 it's fine— and even if the memory actually gets dirty at least you can swap it out. Very few applications handle OOM gracefully and yet on i686 it's not too difficult for a desktop grade system to exhaust the address space. Arguably the continued promotion of i686 is a stability issue. On a longer state. Redesigning that page always causes a painful long list of arguments as everyone wants to be on the top or listed. PPC, KDE, LXDE, and s390 all come out of the woodwork and want a big link on top (or lets randomize it to make it even!). So after the last bikeshedding and my distro is bigger and larger than yours talk.. it was decided to go with one that worked best on the largest install base. As far as I can tell the x86_64 hardware probably already has the largest installed base unless you add all of it's installed base to i686 since x86_64 supports a compatibility mode. I don't believe that adding it makes a lot of sense since that kind of reasoning would have Fedora promoting x86_64 even when i686 was more or less completely extinct. Cheers! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
Jesse Keating jkeat...@j2solutions.net wrote: Richard Hughes hughsi...@gmail.com wrote: On 27 September 2010 19:58, Jaroslav Skarvada jskar...@redhat.com wrote: The character class must be inside bracketed expression, thus double brackets, please see man grep. The new grep-2.7 checks for this common fault: Right, but you could argue it's a regression as the behavior changed. Could somebody please fix docbook-utils, otherwise all the GNOME koji builds are going to fail. Rawhide is acceptable to change like that, particularly this early in the f15 cycle. Unless this change was made in f14. That is not acceptable for f14 at this stage. -- Sent from my Android phone. Please excuse my brevity. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, 27 Sep 2010, Gregory Maxwell wrote: The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? FWIW, we have two measurements of x86_64 vs i686. Smolt: 65% i686 35% x86_64 mirrors.fedoraproject.org: 70% i686 30% x86_64 -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
On 27 September 2010 21:04, Jesse Keating jkeat...@j2solutions.net wrote: Unless this change was made in f14. That is not acceptable for f14 at this stage. I'm using dist-f14. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
Mike McGrath (mmcgr...@redhat.com) said: The Fedora web resources (e.g. http://fedoraproject.org/get-fedora ) continue to promote i686 installs over x86_64, the result being that only a third of fedora users are on x86_64. When will the Fedora project begin recommending x86_64 as the preferred option on the relevant hardware? FWIW, we have two measurements of x86_64 vs i686. Smolt: 65% i686 35% x86_64 mirrors.fedoraproject.org: 70% i686 30% x86_64 What would be interesting is if there's any way at all to see which of these stats is driving the other ... it's sort of a circular relationship. Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 4:12 PM, Mike McGrath mmcgr...@redhat.com wrote: FWIW, we have two measurements of x86_64 vs i686. Smolt: 65% i686 35% x86_64 mirrors.fedoraproject.org: 70% i686 30% x86_64 Right— it's clear that i686 is far more commonly installed today but a non-trivial part of that must be due to the fact that the x86_64 links are hidden. The smolt cpu stats (mhz, number of cores, vendors) suggests that a significant portion of these i686 installs are x86_64 hardware. Though I don't know of any way to gage this precisely. Does anything smolt gathers reliably indicate if the system is x86_64 capable? If so, could that data be made public? I would expect that the i686 install will remain the most common so long as that is what the Fedora project promotes. Drawing attention back to the original post for a moment When will the Fedora project begin recommending x86_64— I wasn't rattling so much for the change to happen now (although I think it should), as much ask asking when it will happen, or really what criteria will be used to determine if we've reached that point yet. I don't think criteria which can never be true (number of systems that can run x86_64 can run i686) or which are nearly circular (existing installed versions; which no-doubt depends strongly on what Fedora chooses to promote) are all that reasonable. Cheers— -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Plan for tomorrow's FESCo meeting (2010-09-28)
Following is the list of topics that will be discussed in the FESCo meeting tomorrow at 19:30UTC (3:30pm EDT) in #fedora-meeting on irc.freenode.net. = Followups = #topic Updates policy #351 Create a policy for updates - status report on implementation https://fedorahosted.org/fesco/ticket/351 #382 Implementing Stable Release Vision https://fedorahosted.org/fesco/ticket/382 #454 pre-release update acceptance criteria https://fedorahosted.org/fesco/ticket/454 See also: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft #topic #434 F15Feature - DNSSEC_on_workstations - https://fedoraproject.org/wiki/Features/DNSSEC_on_workstations https://fedorahosted.org/fesco/ticket/434 #topic #469 App install related issues https://fedorahosted.org/fesco/ticket/469 #topic #467 Make Feature Freeze happen sooner. https://fedorahosted.org/fesco/ticket/467 = New business = #topic #471 FPC Draft for Ratification https://fedorahosted.org/fesco/ticket/471 = Fedora Engineering Services tickets = https://fedorahosted.org/fedora-engineering-services/report/6 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-HTML-FormFu-0.07003-1.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) perl(HTTP::Headers) = 0:1.64 package: perl-HTML-FormFu-0.07003-1.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) perl(HTTP::Headers) = 0:1.64 -- 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: x86_64 as Fedora's primary platform
On 09/27/2010 09:30 PM, Gregory Maxwell wrote: Right— it's clear that i686 is far more commonly installed today but a non-trivial part of that must be due to the fact that the x86_64 links are hidden. The smolt cpu stats (mhz, number of cores, vendors) suggests that a significant portion of these i686 installs are x86_64 hardware. Though I don't know of any way to gage this precisely. Does anything smolt gathers reliably indicate if the system is x86_64 capable? If so, could that data be made public? I would expect that the i686 install will remain the most common so long as that is what the Fedora project promotes. IMHO the spins page are more i686/x86_64 neutral, eg: http://spins.fedoraproject.org/lxde/#downloads -- Athmane Madjoudj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
Michael Schwendt (mschwe...@gmail.com) said: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) Huh? Did perl-libwww-perl disappear? Bill -- 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: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 22:15:48 +0200, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Mon, 27 Sep 2010 21:58:26 +0200, Bruno Wolff III wrote: On Mon, Sep 27, 2010 at 21:50:21 +0200, Jan Kratochvil jan.kratoch...@redhat.com wrote: F14+ livecd-tools have now /usr/bin/mkbiarch for live images automatically choosing x86_64/i686. I was told it is too late for F14 biarch spin but for F15+ that one should be the best default. (With all the movie downloads around please do not reply wrt file size.) It still matters whether or not stuff fits on target media. After CDs have been replaced by DVDs which have been replaced by flash disks(*), have you ever seen a CD-only drive? Popular small notebooks have even no longer a DVD drive. (*) That it makes no sense with Internet is offtopic for what is popular. Some people still burn CDs as they are a bit cheaper. Some file systems in popular use, have file sizes limited to 4 GiB (which is less than fits on a DVD). There are still breakpoints in sizes and these may be more important than being able to run natively in both i686 and x86_64 modes with the same media. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 10:57 PM, Bruno Wolff III br...@wolff.to wrote: On Mon, Sep 27, 2010 at 22:15:48 +0200, Jan Kratochvil jan.kratoch...@redhat.com wrote: On Mon, 27 Sep 2010 21:58:26 +0200, Bruno Wolff III wrote: On Mon, Sep 27, 2010 at 21:50:21 +0200, Jan Kratochvil jan.kratoch...@redhat.com wrote: F14+ livecd-tools have now /usr/bin/mkbiarch for live images automatically choosing x86_64/i686. I was told it is too late for F14 biarch spin but for F15+ that one should be the best default. (With all the movie downloads around please do not reply wrt file size.) It still matters whether or not stuff fits on target media. After CDs have been replaced by DVDs which have been replaced by flash disks(*), have you ever seen a CD-only drive? Popular small notebooks have even no longer a DVD drive. (*) That it makes no sense with Internet is offtopic for what is popular. Some people still burn CDs as they are a bit cheaper. Some file systems in popular use, have file sizes limited to 4 GiB (which is less than fits on a DVD). The x86_64 vs. i686 thing aside ... IMO the CD size limit does more harm than good and should have been lifted a while ago. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 12:30 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I would expect that the i686 install will remain the most common so long as that is what the Fedora project promotes. I wouldn't. We can actually look a little deeper at some of the download stats and take the concept of promotion out of the equation. Lets just look at KDE live downloads from our bittorrent server for Fedora 13. These downloads are not promoted... neither the 32 bit nor the 64bit of the KDE spin get any promotion on the front page nor for that matter does _any_ torrent ticket we offer. Fedora-13-x86_64-Live-KDE: 4591 downloads on our torrent tracker Fedora-13-i686-Live-KDE: 8712 downloads on our torrent tracker So what is that nearly 2/1? You look at all the other unpromoted live spins (anything but the Desktop live spin) on the torrent tracker and you see the same thing. Among the people most likely to look past what we promote..and are willing to spend the clicks to find the install target image from our bittorrent server that they feel best fits their needs...they are _still_ grabbing 32bit primarily. That speaks volumes as to where things are at right now in terms of architecture penetration. More over.. the number of 32bit DVD downloads on the tracker continues to outstrip the 64bit DVD Fedora-13-i386-DVD: 31452 Fedora-13-x86_64-DVD: 20485 Again neither of these are _promoted_ and in fact that exist together in the download options webpage where bittorrent formats are presented. It's very difficult for me to look at the split between 32bit and 64bit downloads in the bittorrent tracker for a given install target category and ascribe the difference in numbers to a promotional bias to any of them other than the Desktop live image which is the only one we promote (we don't even promote it as a torrent.) If anything I would expect the 32bit Desktop Live torrent download activity to be lower because of the promotion of the direct download link of that particular iso. The splits in 32bit and 64bit download activity in the torrent server is very suggestive of a continued preference for 32bit installs regardless of what we promote. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 23:00:45 +0200, drago01 drag...@gmail.com wrote: The x86_64 vs. i686 thing aside ... IMO the CD size limit does more harm than good and should have been lifted a while ago. The CD size limit is self imposed by the Spins that choose to do so. The 4 GiB size limit is a Spins SIG rule, that all published spins are supposed to adhere to. Desktop considered using around a 1 GB target for F13, but in the end decided to stick with being CD sized. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 11:32 PM, Bruno Wolff III br...@wolff.to wrote: On Mon, Sep 27, 2010 at 23:00:45 +0200, drago01 drag...@gmail.com wrote: The x86_64 vs. i686 thing aside ... IMO the CD size limit does more harm than good and should have been lifted a while ago. The CD size limit is self imposed by the Spins that choose to do so. My point was that but it does not fit on a CD is a moot point. The 4 GiB size limit is a Spins SIG rule, that all published spins are supposed to adhere to. Which is fine for now. Desktop considered using around a 1 GB target for F13, but in the end decided to stick with being CD sized. Yeah I know. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Mon, Sep 27, 2010 at 23:35:43 +0200, drago01 drag...@gmail.com wrote: On Mon, Sep 27, 2010 at 11:32 PM, Bruno Wolff III br...@wolff.to wrote: On Mon, Sep 27, 2010 at 23:00:45 +0200, drago01 drag...@gmail.com wrote: The x86_64 vs. i686 thing aside ... IMO the CD size limit does more harm than good and should have been lifted a while ago. The CD size limit is self imposed by the Spins that choose to do so. My point was that but it does not fit on a CD is a moot point. The individual spins groups decide that for their spins. Some of them seem to think targeting CDs is important. I don't know the specific reasons as I am not in any of those groups. (I do handle the Games Spin, but that targets 4 GiB.) If you want to change their minds, you should consider participating in the relavent groups. As for supporting larger possible spin sizes, I am all for that. That's why I pushed for UDF and LZMA support for livecd-tools. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Review request: Nice-to-have bug process documentation proposal
On Fri, 2010-09-24 at 16:22 -0400, James Laska wrote: In practice this is a formalization of existing procedure - until F14 Beta, QA and releng did much the same process but entirely informally, we just kept lists of bugs we'd take fixes for either in our heads or in the RC creation trac tickets. This process is meant to be more robust, documented and discoverable. Perhaps the pending rel-eng SOP documents would cover this, but I'm unclear how FXX-accepted bugs are treated during at compose time. For our current Blocker bug process, it's established that if the appropriate blocker bug list is not empty, we can't compose. With non-blocker nice-to-have (NTH) bugs, how would that fix get into a compose? Guessing ... * The fix would have to be packaged and available in bodhi updates-testing * The bodhi update has received the required karma * The accepted bug is in VERIFIED state? To summarize, what instructions can we provide maintainers with so they can be confident an tested, packaged and approved nice-to-have fix will be pulled into any (re)compose? Perhaps, more of a question for the release-engineering team. So far, we haven't been that strict; the process has been that I've listed any builds currently available in Koji which address nth issues in the RC compose request ticket, and then it's been up to rel-eng to take them or not. I agree we should nail this down a little better, and your list seems reasonable (though I'd probably say it's not necessary that the build be *available* in updates-testing, just that it have been *submitted* there; waiting for an updates-testing compose is an arbitrary limitation). Indeed this is probably something to co-ordinate with releng's SOPs on. Different topic ... In the days of using *only* Blocker bugs, it's now somewhat confusing to look at the F14Beta-accepted tracker, after we started mirroring F14Beta, and see 12 open bugs (some trackers) [1]. I don't think this is a bad thing, but perhaps another item to manage based on the result of the go/no-go meeting ... move any pending FXX-accepted bugs into the next milestone (so open FXXBeta-accepted bugs would move to FXX-accepted)? Yes, I meant to include that and forgot about it. Indeed this should be the process. [1] https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-acceptedhide_resolved=1 Some releng SOP pages may require minor updates, I figured I'd leave that to releng. The process for creating blocker trackers should also be updated to cover creating NTH trackers (I couldn't find that; poelcat, where is it?) https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers I assume User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft is intended to replace QA:SOP_Blocker_Bug_Meeting, and not define an additional blocker review meeting? Yes. I considered creating a separate page detailing a 'nice-to-have review meeting' and noting that in practice it could be combined with the blocker meeting, but that just felt like over-engineering. I've queued https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some additional reading, I'll reply later with any additional comments. Thanks! -- 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
Lookaside failure. Check your cert.
Hello there, I'm having the following error with some of my packages (iverilog and perl-Verilog-Perl) since last week, even after updating my certs. $ fedpkg import /home/chitlesh/rpmbuild/SRPMS/iverilog-0.9.20100928-1.el6.src.rpm Uploading: d004408ea595b13780c4c036f8188b66 verilog-0.9.3.tar.gz Could not import srpm: Lookaside failure. Check your cert. However, I managed to build verilator on koji somehow. Can you please tell me what it may cause this ? Chitlesh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-Module-Build ownership changed
Package perl-Module-Build in Fedora devel is now owned by mmaslano To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-Module-Build -- 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 Module-Build-0.3607.tar.gz uploaded to lookaside cache by mmaslano
A file has been added to the lookaside cache for perl-Module-Build: 9dbbbed68e80e28a9e9f3ab5512a6dab Module-Build-0.3607.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 577669] perl independent sub-package tracking bug.
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=577669 Bug 577669 depends on bug 580447, which changed state. Bug 580447 Summary: Review Request: perl-Module-Build - Build and install Perl modules https://bugzilla.redhat.com/show_bug.cgi?id=580447 What|Old Value |New Value Resolution||RAWHIDE Status|ASSIGNED|CLOSED -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Syntax-Highlight-Perl6-0.87.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Syntax-Highlight-Perl6: 445373f5805512c1643079ff84fd0fa6 Syntax-Highlight-Perl6-0.87.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Syntax-Highlight-Perl6] 0.87 bump
commit f70b002e497d9ba8446492a754ae8e712b761399
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 27 10:12:04 2010 +0200
0.87 bump
Remove merged patch.
.gitignore |1 +
...hlight-Perl6-0.86-Install-script-hilitep6.patch | 24
perl-Syntax-Highlight-Perl6.spec |7 +++--
sources|2 +-
4 files changed, 6 insertions(+), 28 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index ed308e1..af72713 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
Syntax-Highlight-Perl6-0.78.tar.gz
/Syntax-Highlight-Perl6-0.86.tar.gz
+/Syntax-Highlight-Perl6-0.87.tar.gz
diff --git a/perl-Syntax-Highlight-Perl6.spec b/perl-Syntax-Highlight-Perl6.spec
index 79253cd..acd3522 100644
--- a/perl-Syntax-Highlight-Perl6.spec
+++ b/perl-Syntax-Highlight-Perl6.spec
@@ -1,12 +1,11 @@
Name: perl-Syntax-Highlight-Perl6
-Version:0.86
+Version:0.87
Release:1%{?dist}
Summary:Perl 6 Syntax Highlighter
License:(GPL+ or Artistic) and Artistic 2.0 and (MIT or GPLv2)
Group: Development/Libraries
URL:http://search.cpan.org/dist/Syntax-Highlight-Perl6/
Source0:
http://www.cpan.org/authors/id/A/AZ/AZAWAWI/Syntax-Highlight-Perl6-%{version}.tar.gz
-Patch0: %{name}-0.86-Install-script-hilitep6.patch
BuildArch: noarch
# perl(Module::Build) version 0.36 is just autogenerator noise
BuildRequires: perl(Module::Build)
@@ -28,7 +27,6 @@ to build your next great idea.
%prep
%setup -q -n Syntax-Highlight-Perl6-%{version}
-%patch0 -p1
%build
%{__perl} Build.PL installdirs=core
@@ -52,6 +50,9 @@ find $RPM_BUILD_ROOT -depth -type d -exec rmdir {}
2/dev/null \;
%{_mandir}/man3/*
%changelog
+* Mon Sep 27 2010 Petr Pisar ppi...@redhat.com - 0.87-1
+- 0.87 bump (RT#61522)
+
* Tue Sep 21 2010 Petr Pisar ppi...@redhat.com - 0.86-1
- 0.86 bump
- Move from ExtUtils::Maker to Module::Build
diff --git a/sources b/sources
index 6a2ce41..63190b7 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-3a92c0fc5b15aee4909e8097734330e2 Syntax-Highlight-Perl6-0.86.tar.gz
+445373f5805512c1643079ff84fd0fa6 Syntax-Highlight-Perl6-0.87.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 threads-shared-1.33.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-threads-shared: 59e5882c75033835d44d0ab3bfc02c60 threads-shared-1.33.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-threads-shared] 1.33 import
commit 62fb8ea927e4ac2c76d848e6cf84eedaf680ec82
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 27 10:23:35 2010 +0200
1.33 import
.gitignore |1 +
perl-threads-shared.spec | 63 ++
sources |1 +
3 files changed, 65 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..6001a3d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/threads-shared-1.33.tar.gz
diff --git a/perl-threads-shared.spec b/perl-threads-shared.spec
new file mode 100644
index 000..8f4371a
--- /dev/null
+++ b/perl-threads-shared.spec
@@ -0,0 +1,63 @@
+Name: perl-threads-shared
+Version:1.33
+Release:1%{?dist}
+Summary:Perl extension for sharing data structures between threads
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/threads-shared/
+Source0:
http://www.cpan.org/authors/id/J/JD/JDHEDDEN/threads-shared-%{version}.tar.gz
+BuildRequires: perl(Carp)
+BuildRequires: perl(Config)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::testlib)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(threads) = 1.73
+BuildRequires: perl(XSLoader)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Carp)
+Requires: perl(threads) = 1.73
+Requires: perl(XSLoader)
+
+%{?perl_default_filter}
+
+%description
+By default, variables are private to each thread, and each newly created
+thread gets a private copy of each existing variable. This module allows
+you to share variables across different threads (and pseudo-forks on
+Win32). It is used together with the threads module.
+
+%prep
+%setup -q -n threads-shared-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=perl OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} 2/dev/null \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%defattr(-,root,root,-)
+%doc Changes README
+%{perl_archlib}/auto/*
+%{perl_archlib}/threads*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Sep 23 2010 Petr Pisar ppi...@redhat.com 1.33-1
+- Specfile autogenerated by cpanspec 1.78.
+- Fix dependencies
+- Requires perl(Scalar::Util) is autodetected
+- Do not provide private library
+- Remove pre-F12 BuildRoot stuff
diff --git a/sources b/sources
index e69de29..42462a4 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+59e5882c75033835d44d0ab3bfc02c60 threads-shared-1.33.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-App-cpanminus] 1.0015 bump
commit 6cf64fcbace08ccfdafbf042588b121b14101eda
Author: Petr Písař ppi...@redhat.com
Date: Mon Sep 27 11:00:45 2010 +0200
1.0015 bump
.gitignore |1 +
perl-App-cpanminus.spec |5 -
sources |2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 49344a0..e03f780 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
App-cpanminus-0.9935.tar.gz
/App-cpanminus-1.0013.tar.gz
/App-cpanminus-1.0014.tar.gz
+/App-cpanminus-1.0015.tar.gz
diff --git a/perl-App-cpanminus.spec b/perl-App-cpanminus.spec
index 3a9ec05..d64ae7a 100644
--- a/perl-App-cpanminus.spec
+++ b/perl-App-cpanminus.spec
@@ -1,5 +1,5 @@
Name: perl-App-cpanminus
-Version:1.0014
+Version:1.0015
Release:1%{?dist}
Summary:Library for get, unpack, build and install CPAN modules
License:GPL+ or Artistic
@@ -71,6 +71,9 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man1/*
%changelog
+* Mon Sep 27 2010 Petr Pisar ppi...@redhat.com - 1.0015-1
+- 1.0015 bump
+
* Thu Sep 23 2010 Petr Pisar ppi...@redhat.com - 1.0014-1
- 1.0014 bump
diff --git a/sources b/sources
index b9f1ec1..cf6c014 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-773ad8ef5411a8c0d47cc39b9b8be5c8 App-cpanminus-1.0014.tar.gz
+61581df059c48d1aea03e8f1e919df27 App-cpanminus-1.0015.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 637375] perl-App-cpanminus-1.0015 is available
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=637375 Petr Pisar ppi...@redhat.com changed: What|Removed |Added CC|mmasl...@redhat.com,| |psab...@redhat.com | AssignedTo|mmasl...@redhat.com |ppi...@redhat.com -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File App-cpanminus-1.0015.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-App-cpanminus: 61581df059c48d1aea03e8f1e919df27 App-cpanminus-1.0015.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 637375] perl-App-cpanminus-1.0015 is available
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=637375 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpanminus-1.0015-1 ||.fc15 Resolution||NEXTRELEASE Last Closed||2010-09-27 05:07:56 -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 633737] perl-Padre-0.70 is available
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=633737 Bug 633737 depends on bug 636545, which changed state. Bug 636545 Summary: threads-shared-1.33 bump https://bugzilla.redhat.com/show_bug.cgi?id=636545 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|CLOSED Resolution||NEXTRELEASE -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 357641] EL branches perl-Tk
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=357641 Xavier Bachelot xav...@bachelot.org changed: What|Removed |Added CC||andreas.bierf...@lowlatency ||.de Component|perl-Tk |perl-Tk Version|14 |el6 Product|Fedora |Fedora EPEL --- Comment #4 from Xavier Bachelot xav...@bachelot.org 2010-09-27 16:16:25 EDT --- Andreas, any update on the EL6 branch ? Changing the product to Fedora EPEL, it'll help with triaging. Thanks, Xavier -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Unit-Runner-Xml/el6/master] (5 commits) ...Merge branch 'master' into el6
Summary of changes: b3ffb1c... Fix typo that causes a failure to update the common directo (*) d62cc57... - rebuild against perl 5.10.1 (*) badd2c5... - Mass rebuild with perl-5.12.0 (*) 8274a33... dist-git conversion (*) 9fe0038... Merge branch 'master' into el6 (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 357641] EL branches perl-Tk
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=357641 Xavier Bachelot xav...@bachelot.org changed: What|Removed |Added Status Whiteboard||PackageBranch -- 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-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-HTTP-Body-1.07-2.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) package: perl-HTTP-Body-1.07-2.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-Catalyst-Runtime-5.80025-1.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) perl(HTTP::Headers) = 0:1.64 package: perl-Catalyst-Runtime-5.80025-1.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) perl(HTTP::Headers) = 0:1.64 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-OpenFrame-3.05-12.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) package: perl-OpenFrame-3.05-12.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: rt3-3.8.8-3.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) package: rt3-3.8.8-3.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) -- 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: Broken dependencies with Fedora 14 + updates-testing - 2010-09-27
On 09/27/2010 10:51 PM, Bill Nottingham wrote: Michael Schwendt (mschwe...@gmail.com) said: The following packages in the repository suffer from broken dependencies: == The results in this summary consider Test Updates! == package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-i386 unresolved deps: perl(HTTP::Headers) package: perl-Finance-Quote-1.17-3.fc14.noarch from fedora-14-development-x86_64 unresolved deps: perl(HTTP::Headers) Huh? Did perl-libwww-perl disappear? No. Marcela screwed the package. Seemingly she is trying to filter out duplicate provides rpm generates and now filters too much. Ralf -- 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
