Package Review Stats for last week ending 26th Sept
Top three FAS account holders who have completed reviewing Package review components on bugzilla for last week ending 26th Sept were Parag AN(पराग), Peter Lemenkov and Martin Gieseking. Parag AN(पराग) : 8 https://bugzilla.redhat.com/show_bug.cgi?id=635654 perl-Text-Hunspell https://bugzilla.redhat.com/show_bug.cgi?id=225821 gnome-mag (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=225823 gnome-menus (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226016 libgnomeprint22 (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226059 libwnck (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226087 libXScrnSaver (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226095 libXxf86misc (Merge Review) https://bugzilla.redhat.com/show_bug.cgi?id=226096 libXxf86vm (Merge Review) Peter Lemenkov : 5 https://bugzilla.redhat.com/show_bug.cgi?id=540885 CableSwig https://bugzilla.redhat.com/show_bug.cgi?id=635515 libphidget https://bugzilla.redhat.com/show_bug.cgi?id=589866 darktable https://bugzilla.redhat.com/show_bug.cgi?id=634906 http-parser https://bugzilla.redhat.com/show_bug.cgi?id=634908 libeio Martin Gieseking : 4 https://bugzilla.redhat.com/show_bug.cgi?id=623604 xneur https://bugzilla.redhat.com/show_bug.cgi?id=626446 libmutil https://bugzilla.redhat.com/show_bug.cgi?id=620898 nxtrc https://bugzilla.redhat.com/show_bug.cgi?id=631190 libnxt Alexander Kurtakov : 3 https://bugzilla.redhat.com/show_bug.cgi?id=636209 atinject https://bugzilla.redhat.com/show_bug.cgi?id=634622 eclipse-p2-discovery https://bugzilla.redhat.com/show_bug.cgi?id=631558 arduino Marcela Mašláňová : 3 https://bugzilla.redhat.com/show_bug.cgi?id=633879 perl-Test-Inter https://bugzilla.redhat.com/show_bug.cgi?id=636107 perl-STD https://bugzilla.redhat.com/show_bug.cgi?id=636892 perl-threads-shared Radek Novacek : 2 https://bugzilla.redhat.com/show_bug.cgi?id=627197 bluedevil https://bugzilla.redhat.com/show_bug.cgi?id=568968 spyder Robin Lee : 2 https://bugzilla.redhat.com/show_bug.cgi?id=567348 dreampie https://bugzilla.redhat.com/show_bug.cgi?id=634388 python-chameleon Andrew Beekhof : 1 https://bugzilla.redhat.com/show_bug.cgi?id=619799 mingw32-pcre Ben Boeckel : 1 https://bugzilla.redhat.com/show_bug.cgi?id=620046 ghc-terminfo Guillermo Gómez : 1 https://bugzilla.redhat.com/show_bug.cgi?id=624833 dhcp_probe Jan Kaluža : 1 https://bugzilla.redhat.com/show_bug.cgi?id=631898 fatrat Jeff Johnston : 1 https://bugzilla.redhat.com/show_bug.cgi?id=634543 animal-sniffer Mamoru Tasaka : 1 https://bugzilla.redhat.com/show_bug.cgi?id=633549 rubygem-linode Michael Stahnke : 1 https://bugzilla.redhat.com/show_bug.cgi?id=635126 rubygem-test-unit Michel Alexandre Salim : 1 https://bugzilla.redhat.com/show_bug.cgi?id=614520 gnustep-examples Orion Poplawski : 1 https://bugzilla.redhat.com/show_bug.cgi?id=636250 HotEqn Paul Lange : 1 https://bugzilla.redhat.com/show_bug.cgi?id=635451 gio-sharp Petr Pisar : 1 https://bugzilla.redhat.com/show_bug.cgi?id=636945 perl-Convert-UU Stanislav Ochotnicky : 1 https://bugzilla.redhat.com/show_bug.cgi?id=225953 jsch (Merge Review) Total reviews modified: 39 Merge Reviews: 8 Review Requests: 31 This report by generated by bzReviewReport.py. The source is available at: https://fedorahosted.org/triage/browser/scripts/bzReviewReport.py Please submit patches or bug reports at: https://fedorahosted.org/triage/ -- 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
[Test-Announce] Graphics Test Week this week! 2010-09-28: Nouveau
It's been creeping up, and now it's time: the world-famous Graphics Test Week begins tomorrow (2010-09-28), with the Nouveau Test Day [1]. As always, the event runs all day in #fedora-test-day on Freenode IRC. To complete Graphics Test Week, the Radeon Test Day [2] takes place the following day, Wednesday 2010-09-29, and the Intel Test Day [3] takes place Thursday 2010-09-30. As always, we'll be testing a range of graphics driver functions, and we need as many people as possible to join in so we can evaluate the widest possible range of hardware and identify as many bugs as possible for the developers to fix. You can do all the testing from a live image - no need for an installed copy of Fedora 14, though you can test that way too if you like - and the testing is very easy, there are step-by-step instructions for each test and for entering your results. And of course, there'll be many people in IRC to help with testing and debugging. If you can't make the nominated Test Day for your hardware, your testing is still just as valuable: you can do the testing any other day and add your results to the table on the Wiki page. [1] https://fedoraproject.org/wiki/Test_Day:2010-09-28_Nouveau [2] https://fedoraproject.org/wiki/Test_Day:2010-09-29_Radeon [3] https://fedoraproject.org/wiki/Test_Day:2010-09-30_Intel -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. To a first order approximation, if you have 64-bit hardware, then a 64-bit spin is better. We know that, but how many of our users do? The strong suggestion we make is that 32-bit is the default, and in the absence of any other information I'll always go for the default. As will most people... Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 9:37 AM, Andrew Haley a...@redhat.com wrote: On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. To a first order approximation, if you have 64-bit hardware, then a 64-bit spin is better. We know that, but how many of our users do? The strong suggestion we make is that 32-bit is the default, and in the absence of any other information I'll always go for the default. As will most people... May I chip in another thought here? Although in principle it is better if 64 bit versions are used on capable hardware there still remains a series of issues with some code - eg firefox and thunderbird are not always built for 64 bit and there are issues with corresponding extensions and multilib library issues as a consquence. If the default were made 64 bit then these kinds of issues would come to the fore in quite large numbers. I believe that keeping i686 as the default and letting users decide to opt in to 64 bit is the right way forward until the number of 64 bit specific problems reduces to acceptable levels. -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 09/28/2010 12:06 PM, mike cloaked wrote: On Tue, Sep 28, 2010 at 9:37 AM, Andrew Haley a...@redhat.com wrote: On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. To a first order approximation, if you have 64-bit hardware, then a 64-bit spin is better. We know that, but how many of our users do? The strong suggestion we make is that 32-bit is the default, and in the absence of any other information I'll always go for the default. As will most people... May I chip in another thought here? Although in principle it is better if 64 bit versions are used on capable hardware there still remains a series of issues with some code - eg firefox and thunderbird are not always built for 64 bit Huh? Sure they are. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20100928 changes
Compose started at Tue Sep 28 08:15:11 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) rubygem-cucumber-0.9.0-4.fc15.noarch requires rubygem(gherkin) = 0:2.2.4 sipwitch-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit) sipwitch-cgi-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit) sipwitch-plugin-forward-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit) sipwitch-plugin-scripting-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit) sipwitch-plugin-subscriber-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit) sipwitch-plugin-zeroconf-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit) sipwitch-runtime-0.9.0-0.fc15.i686 requires libucommon.so.3 sipwitch-runtime-0.9.0-0.fc15.x86_64 requires libucommon.so.3()(64bit)
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 1:29 PM, Andrew Haley a...@redhat.com wrote: On 09/28/2010 12:06 PM, mike cloaked wrote: On Tue, Sep 28, 2010 at 9:37 AM, Andrew Haley a...@redhat.com wrote: On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. To a first order approximation, if you have 64-bit hardware, then a 64-bit spin is better. We know that, but how many of our users do? The strong suggestion we make is that 32-bit is the default, and in the absence of any other information I'll always go for the default. As will most people... May I chip in another thought here? Although in principle it is better if 64 bit versions are used on capable hardware there still remains a series of issues with some code - eg firefox and thunderbird are not always built for 64 bit Huh? Sure they are. Some people use nightlies for example - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/ Here there are no 64 bit versions that I am aware of? I do this when the stock version is somewhat behind even the stable release from mozilla. eg in f12 the current thunderbird is 3.1.4 but the current f12 version is 3.0.7, and similar for firefox. Yet this is still a supported release - yes f13 is up to current stable releases from mozilla for both of these. However in the mozilla filestore for latest stable for thunderbird at: http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.1.4/linux-i686/en-GB/ there is no 64 bit version, so if running 64 bit f12 then it would be necessary to install the 32 bit thunderbird and make sure that necessary 32 bit libraries were also installed to make it run? However in the future, say when f15 is still supported but f16 is current, it may well be that it is more work to run applications such as this that are more up to date than the Fedora packages either by messing with multilib library install or building the application for 64 bit from source. There must be quite a few other examples where people will want to run specific codes that are not built for 64 bit? To take the hassle out of dealing with issues like this I install 32 bit and life is a bit easier! However no doubt the best decision will emerge from the discussion? -- mike c -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 09/28/2010 03:58 PM, mike cloaked wrote: On Tue, Sep 28, 2010 at 1:29 PM, Andrew Haley a...@redhat.com wrote: On 09/28/2010 12:06 PM, mike cloaked wrote: On Tue, Sep 28, 2010 at 9:37 AM, Andrew Haley a...@redhat.com wrote: On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. To a first order approximation, if you have 64-bit hardware, then a 64-bit spin is better. We know that, but how many of our users do? The strong suggestion we make is that 32-bit is the default, and in the absence of any other information I'll always go for the default. As will most people... May I chip in another thought here? Although in principle it is better if 64 bit versions are used on capable hardware there still remains a series of issues with some code - eg firefox and thunderbird are not always built for 64 bit Huh? Sure they are. Some people use nightlies for example - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/ Here there are no 64 bit versions that I am aware of? I do this when the stock version is somewhat behind even the stable release from mozilla. eg in f12 the current thunderbird is 3.1.4 but the current f12 version is 3.0.7, and similar for firefox. Yet this is still a supported release - yes f13 is up to current stable releases from mozilla for both of these. However in the mozilla filestore for latest stable for thunderbird at: http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/3.1.4/linux-i686/en-GB/ there is no 64 bit version, so if running 64 bit f12 then it would be necessary to install the 32 bit thunderbird and make sure that necessary 32 bit libraries were also installed to make it run? Maybe there's something that I miss here, but the fact that the mozilla devs do not find necessary (or maybe they do not have the computing power...) to build 64bit binaries each day ( but mind that they DO build the 4 beta series for x86_64 ! ) has nothing to do with fedora's policy about 64bit apps, does it ? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 09/28/2010 01:58 PM, mike cloaked wrote: On Tue, Sep 28, 2010 at 1:29 PM, Andrew Haley a...@redhat.com wrote: On 09/28/2010 12:06 PM, mike cloaked wrote: On Tue, Sep 28, 2010 at 9:37 AM, Andrew Haley a...@redhat.com wrote: On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. To a first order approximation, if you have 64-bit hardware, then a 64-bit spin is better. We know that, but how many of our users do? The strong suggestion we make is that 32-bit is the default, and in the absence of any other information I'll always go for the default. As will most people... May I chip in another thought here? Although in principle it is better if 64 bit versions are used on capable hardware there still remains a series of issues with some code - eg firefox and thunderbird are not always built for 64 bit Huh? Sure they are. Some people use nightlies for example - http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-1.9.2/ Here there are no 64 bit versions that I am aware of? I do this when the stock version is somewhat behind even the stable release from mozilla. Sure, but that's such a weird case that it's hardly relevant to the person who just wants a default Fedora. People who really need bleeding-edge Thunderbird presumably know who they are. There must be quite a few other examples where people will want to run specific codes that are not built for 64 bit? Of course, but that's hardly relevant here. This message was sent to you from thunderbird-3.1.5pre, downloaded from from that URL, running on my 64-bit Fedora system. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 8:58 AM, mike cloaked mike.cloa...@gmail.com wrote: Huh? Sure they are. Some people use nightlies for example - Here there are no 64 bit versions that I am aware of? I do this when the stock version is somewhat behind even the stable release from mozilla. eg in f12 the current thunderbird is 3.1.4 but the current f12 version is 3.0.7, and similar for firefox. Yet this is still a supported release - yes f13 is up to current stable releases from mozilla for both of these. However in the mozilla filestore for latest stable for thunderbird at: Mozilla only builds x86_64 for trunk builds: http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ If you're not interested in the bleeding edge, why not run what Fedora provides? ...and if more people were using x86_64 Linux then perhaps Mozilla would bother building the other branches for it. [snip] However in the future, say when f15 is still supported but f16 is current, it may well be that it is more work to run applications such as this that are more up to date than the Fedora packages either by messing with multilib library install or building the application for 64 bit from source. The traditional way to get future packages is to pull them back from later Fedora versions— though this doesn't always work, nor does taking packages from a third party. There must be quite a few other examples where people will want to run specific codes that are not built for 64 bit? To take the hassle out of dealing with issues like this I install 32 bit and life is a bit easier! Not fedora packages, however. Third party, especially binary only things... Sure. But the way to move forward there is to get x86_64 the default— the technical issues are solved, only market share will convince the stragglers. And besides, Fedora is a center for innovation in free and open source software and 1/3rd of Fedora users are already on it. Nothing is bug free— but Fedora's 64 bit support is about as close as anything available to me, and has been for some time. Advising caution 'until the bugs were worked out' might have been reasonable long ago, but not anymore. As far as I can tell the only big reason to lead with i686 is simply because if x86_64 is promoted some people will download the wrong version for their hardware and have trouble installing. It's a real concern, but I think that Fedora's commitment to innovation should take priority, as it has taken priority over small usability issues every time Fedora has updated some major piece of infrastructure to a new version. However no doubt the best decision will emerge from the discussion? No doubt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
Jan Kratochvil 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. Doubling the live image size just to support the obsolete 32-bit-only machines with the default image? Not a good solution. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-14 Branched report: 20100928 changes
Compose started at Tue Sep 28 13:15:26 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: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 09:37:06AM +0100, Andrew Haley wrote: On 09/27/2010 10:03 PM, Jeff Spaleta wrote: 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. Sure, but the question is how much of that is simply due to a lack of awareness. lack of awareness of advantages perhaps? One issue - many people have a mix of systems not all 64 bit capable. As long as the advantages are not overwhelming many of those will stick to a single variant for practical reasons and obviously that can only be 32 bit. Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
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. x86_64 will also work on an overwhelming majority of hardware around. Basically all non-netbook x86 hardware made in the last few years is 64-bit! until i686 is uncommon (which is still not yet) It is. Excepting netbooks, you'll be hard-pressed to find a 32-bit-only machine that's less than 3+ years old. I think we should keep the default i686. I think the default should be x86_64, with a clear message saying where to download the 32-bit version if it's run on a 32-bit-only machine (something which can probably be implemented with a simple GRUB patch). That way all users get the optimal Fedora for their hardware. Many people run the legacy 32-bit version on hardware which would run the 64-bit version just fine because they don't find the 64-bit version or because they think the 32-bit one is somehow better supported since we offer it by default (they might have some past bad experiences with multilib-by- default and the resulting problems, but these days we default to pure 64-bit which doesn't have any of those multilib issues), and 32-bit x86 is known to be slow. (FWIW, I also think there should be no one default download, instead the get-fedora-options page should become the default get-fedora download page. But that's a matter for another flamewar. ;-) ) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, 2010-09-28 at 17:32 +0200, Kevin Kofler wrote: 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. x86_64 will also work on an overwhelming majority of hardware around. Basically all non-netbook x86 hardware made in the last few years is 64-bit! until i686 is uncommon (which is still not yet) It is. Excepting netbooks, you'll be hard-pressed to find a 32-bit-only machine that's less than 3+ years old. Why do you think it's a good idea to except netbooks? And why do you assume running Fedora on a three year old machine isn't a fairly common case? (I have both 3+ year old 32-bit only machines and netbooks running Linux right here at home). -- 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: x86_64 as Fedora's primary platform
Adam Williamson wrote: Why do you think it's a good idea to except netbooks? And why do you assume running Fedora on a three year old machine isn't a fairly common case? (I have both 3+ year old 32-bit only machines and netbooks running Linux right here at home). The compromise is that the web team should be sniffing the User Agent of the browser for the machine arch and present a download option to match. Scenario: You are running a 32-bit browser on a 64-bit machine and browse Fedoraproject.org. Fedoraproject.org should present a 64-bit installer. Yes, it can be done. The user agent, at least for Firefox, contains the machine arch even if you use the 32-bit browser. There is no valid, non-subjective reason to continue running a 32-bit kernel on a 64-bit system. This entire thread is a nice joke to read. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, 2010-09-28 at 11:05 -0500, Michael Cronenworth wrote: Adam Williamson wrote: Why do you think it's a good idea to except netbooks? And why do you assume running Fedora on a three year old machine isn't a fairly common case? (I have both 3+ year old 32-bit only machines and netbooks running Linux right here at home). The compromise is that the web team should be sniffing the User Agent of the browser for the machine arch and present a download option to match. Scenario: You are running a 32-bit browser on a 64-bit machine and browse Fedoraproject.org. Fedoraproject.org should present a 64-bit installer. Yes, it can be done. The user agent, at least for Firefox, contains the machine arch even if you use the 32-bit browser. That's a neat idea, but presupposes the machine you're downloading with is the only one you intend to use the image on. There is no valid, non-subjective reason to continue running a 32-bit kernel on a 64-bit system. This entire thread is a nice joke to read. I don't believe anyone said there was, so this is a straw man. -- 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: x86_64 as Fedora's primary platform
mike cloaked wrote: May I chip in another thought here? Although in principle it is better if 64 bit versions are used on capable hardware there still remains a series of issues with some code - eg firefox and thunderbird are not always built for 64 bit In Fedora it is, in Remi Collet's repository as well. I believe that keeping i686 as the default and letting users decide to opt in to 64 bit is the right way forward until the number of 64 bit specific problems reduces to acceptable levels. Huh? All the 64-bit-specific problems are gone now that we no longer install the legacy 32-bit multilibs by default. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: docbook and glibc breakage?
Bill Nottingham wrote: Exactly... this is way late to be introducing this into Fedora 14. Any reason it can't be held for F15? (Bug filed to this effect.) The old behavior of that expression is not what the code probably expected, it just happened to silently do the wrong thing instead of throwing an error. The code which now errors needs to be fixed anyway. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
Adam Williamson wrote: Why do you think it's a good idea to except netbooks? The netbook issue can be solved by a simple Download Netbook Version link (along with a clear warning on the default download that it's only for desktop/laptop computers and that netbook users must use the netbook version). Users who have a netbook know they have a netbook (so the but the user doesn't know his machine is not 64-bit capable argument is irrelevant there). And the netbook version can also use an environment better suited for netbooks (e.g. Plasma Netbook, MeeGo or maybe LXDE). And why do you assume running Fedora on a three year old machine isn't a fairly common case? I'm saying 3+ because I don't know the exact number to write there, but I think it's more than 3. (I have both 3+ year old 32-bit only machines and netbooks running Linux right here at home). Look, I'm typing this on a 32-bit-only machine. But I KNOW the machine is old and doesn't support Intel 64 (formerly called EM64T and even before IA-32e). What are the chances that a user who's new enough to not know what 64-bit means has such an old computer? I won't have any trouble finding the 32-bit downloads for my 32-bit PC even if x86_64 is the default. (And FWIW, I also have a 64-bit notebook (Core 2 Duo), of course running the x86_64 version. I don't see why I'd run a legacy 32-bit version on it.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
Adam Williamson wrote: That's a neat idea, but presupposes the machine you're downloading with is the only one you intend to use the image on. It also presupposes it's running a 64-bit kernel if it's 64-bit capable. The browser isn't going to tell you the CPU's LM flag. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Lookaside failure. Check your cert.
On Tuesday, September 28, 2010 12:13:49 am Chitlesh GOORAH wrote: 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 did you recently get a new cert? if so you may need to update nss. if your using rhel6 you should use fedora or convert the cert to a format nss understands (openssl x509 -in ~/.fedora.cert -text; echo; openssl rsa -in ~/.fedora.cert) fedora.cert.new Dennis 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: x86_64 as Fedora's primary platform
Richard Zidlicky wrote: One issue - many people have a mix of systems not all 64 bit capable. As long as the advantages are not overwhelming many of those will stick to a single variant for practical reasons and obviously that can only be 32 bit. I have a 32-bit and a 64-bit machine, I run the 32-bit edition on the 32-bit one and the 64-bit edition on the 64-bit one and I really don't see why I'd do anything else. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, 28 Sep 2010, Kevin Kofler wrote: Richard Zidlicky wrote: One issue - many people have a mix of systems not all 64 bit capable. As long as the advantages are not overwhelming many of those will stick to a single variant for practical reasons and obviously that can only be 32 bit. I have a 32-bit and a 64-bit machine, I run the 32-bit edition on the 32-bit one and the 64-bit edition on the 64-bit one and I really don't see why I'd do anything else. We run 32 bit vms in Fedora Infrastructure a lot for purposes of memory density, we do it based on what will be running on the host as it doesn't always make sense to do so. It's worked out very well for us. -Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
Adam Williamson wrote: That's a neat idea, but presupposes the machine you're downloading with is the only one you intend to use the image on. Yet, many web sites I frequent use what I proposed. http://www.mozilla.com http://www.pidgin.im Two examples for you to chew on. They have a nice Other Downloads type button that I have to use constantly because I only visit those sites to download the Windows EXE file - when I am on my Fedora machines. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-09-28)
On Mon, Sep 27, 2010 at 02:32:03PM -0600, Kevin Fenzi wrote: 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. Sorry, got to send my regrets. Again, I've got to commute for a class at 4pm. I'd like to stand aside and let someone else take my place, as there's no way I'll be able to make the meeting for the next 10 weeks... regards, Kyle -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, 2010-09-28 at 13:10 -0500, Michael Cronenworth wrote: Adam Williamson wrote: That's a neat idea, but presupposes the machine you're downloading with is the only one you intend to use the image on. Yet, many web sites I frequent use what I proposed. http://www.mozilla.com http://www.pidgin.im Two examples for you to chew on. Which really aren't the same, because they're *software application* download sites which are detecting the OS you currently have installed in the assumption that that's likely what you want to install the software on. -- 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: x86_64 as Fedora's primary platform
Adam Williamson wrote: Which really aren't the same, because they're*software application* download sites which are detecting the OS you currently have installed in the assumption that that's likely what you want to install the software on. OK, I think I've pinpointed where the conflict of interest originates. Adam, people aren't looking for installing an OS every day. They look for software to install every day. Most users are familiar with sites like I mentioned. Where do I coin the term most? From web statistics that show Windows has a majority of the market. If you don't want to target most users then fine - I'll shut up. PS. I was well aware that Mozilla Firefox and Pidgin are just one software compared to Fedora which is a distribution of software. No need to belittle me as you have continued to do. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 8:09 PM, Mike McGrath mmcgr...@redhat.com wrote: On Tue, 28 Sep 2010, Kevin Kofler wrote: Richard Zidlicky wrote: One issue - many people have a mix of systems not all 64 bit capable. As long as the advantages are not overwhelming many of those will stick to a single variant for practical reasons and obviously that can only be 32 bit. I have a 32-bit and a 64-bit machine, I run the 32-bit edition on the 32-bit one and the 64-bit edition on the 64-bit one and I really don't see why I'd do anything else. We run 32 bit vms in Fedora Infrastructure a lot for purposes of memory density, we do it based on what will be running on the host as it doesn't always make sense to do so. It's worked out very well for us. That's a valid case where it indeed makes sense, but I assume the *host* is running x86_64. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, 2010-09-28 at 13:37 -0500, Michael Cronenworth wrote: Adam Williamson wrote: Which really aren't the same, because they're*software application* download sites which are detecting the OS you currently have installed in the assumption that that's likely what you want to install the software on. OK, I think I've pinpointed where the conflict of interest originates. Er, what? Adam, people aren't looking for installing an OS every day. They look for software to install every day. Most users are familiar with sites like I mentioned. Where do I coin the term most? From web statistics that show Windows has a majority of the market. All of these things are factually true, but I'm not entirely sure what point you're making. If you don't want to target most users then fine - I'll shut up. Um, huh? PS. I was well aware that Mozilla Firefox and Pidgin are just one software compared to Fedora which is a distribution of software. No need to belittle me as you have continued to do. I certainly didn't intend to do so. To be honest, this mail just baffles me, I have no idea what you're saying exactly. -- 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: x86_64 as Fedora's primary platform
On 09/28/2010 11:37 AM, drago01 wrote: On Tue, Sep 28, 2010 at 8:09 PM, Mike McGrath mmcgr...@redhat.com wrote: We run 32 bit vms in Fedora Infrastructure a lot for purposes of memory density, we do it based on what will be running on the host as it doesn't always make sense to do so. It's worked out very well for us. That's a valid case where it indeed makes sense, but I assume the *host* is running x86_64. A x86_64 kernel with everything else i686 [no 64-bit apps] can be good non-virtually, too, particularly when it avoids 32-bit PAE for more than 3.3GB of RAM. -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2010 02:49 PM, John Reiser wrote: On 09/28/2010 11:37 AM, drago01 wrote: On Tue, Sep 28, 2010 at 8:09 PM, Mike McGrath mmcgr...@redhat.com wrote: We run 32 bit vms in Fedora Infrastructure a lot for purposes of memory density, we do it based on what will be running on the host as it doesn't always make sense to do so. It's worked out very well for us. That's a valid case where it indeed makes sense, but I assume the *host* is running x86_64. A x86_64 kernel with everything else i686 [no 64-bit apps] can be good non-virtually, too, particularly when it avoids 32-bit PAE for more than 3.3GB of RAM. Perhaps we could try something a little different? Have three options on the download page: Option 1) Netbooks or hardware three years or more old (32-bit) Option 2) New, non-netbook hardware (64-bit) Option 3) Small text link leading to complete download list, including spins like KDE and XFCE Or just have the download page provide a link to List all download options or Ask me some questions about my hardware (with every question offering an I don't know option) - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyiOj0ACgkQeiVVYja6o6NE8QCbBdCXO6F5JSHjGbxH+DOizj0j /XQAmgMppriKkmLgmqxbiDoNdLwlyjr9 =1IL1 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 8:49 PM, John Reiser jrei...@bitwagon.com wrote: On 09/28/2010 11:37 AM, drago01 wrote: On Tue, Sep 28, 2010 at 8:09 PM, Mike McGrath mmcgr...@redhat.com wrote: We run 32 bit vms in Fedora Infrastructure a lot for purposes of memory density, we do it based on what will be running on the host as it doesn't always make sense to do so. It's worked out very well for us. That's a valid case where it indeed makes sense, but I assume the *host* is running x86_64. A x86_64 kernel with everything else i686 [no 64-bit apps] can be good non-virtually, too, particularly when it avoids 32-bit PAE for more than 3.3GB of RAM. No it is pointless in 99% of the times, you lose stuff like: SSE2 being part of the standard ABI and additional registers for no real gain. (which can result into none or huge performance differences depending on the situation). -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On Tue, Sep 28, 2010 at 10:55 AM, Stephen Gallagher sgall...@redhat.com wrote: Or just have the download page provide a link to List all download options this exists now in multiple forms on the http://fedoraproject.org/get-fedora page In the central frame More download options... right under the big download button for the promoted live image gets you to a set of Spin pages that list 32bit and 64bit download links side by side. In the text box beneath that which goes into some minor detail about the options there is the same link using the words View more Fedora options... This box even brings up 32/64 bit architecture an option. In the sidebar at the bottom Other ways to get Fedora has a link which is more comprehensive still. -jef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Plan for tomorrow's FESCo meeting (2010-09-28)
On Tue, 28 Sep 2010 14:26:09 -0400 Kyle McMartin k...@mcmartin.ca wrote: On Mon, Sep 27, 2010 at 02:32:03PM -0600, Kevin Fenzi wrote: 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. Sorry, got to send my regrets. Again, I've got to commute for a class at 4pm. I'd like to stand aside and let someone else take my place, as there's no way I'll be able to make the meeting for the next 10 weeks... Very sorry to hear it. ;( We could look at changing time, but I recall that was a struggle with the constraints people have. ;( kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: x86_64 as Fedora's primary platform
On 09/28/2010 11:57 AM, drago01 wrote: On Tue, Sep 28, 2010 at 8:49 PM, John Reiser jrei...@bitwagon.com wrote: A x86_64 kernel with everything else i686 [no 64-bit apps] can be good non-virtually, too, particularly when it avoids 32-bit PAE for more than 3.3GB of RAM. No it is pointless in 99% of the times, you lose stuff like: SSE2 being part of the standard ABI and additional registers for no real gain. (which can result into none or huge performance differences depending on the situation). Being able to run 3000 simultaneous processes (32-bit) instead of only 2400 processes (64-bit) can be an advantage that out-weighs the minor losses to each individual process. RAM is cheap [and a capital cost], racks are expensive [and an operating cost for power, cooling, rent.] -- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Minutes/Summary from today's FESCo meeting (2010-09-28)
=== #fedora-meeting: FESCO (2010-09-28) === Meeting started by nirik at 19:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-09-28/fesco.2010-09-28-19.30.log.html Meeting summary --- * init process (nirik, 19:30:01) * Kylem unable to attend meetings in this timeslot (nirik, 19:34:28) * LINK: http://whenisgood.net/ee8prq/results/z5binx (nirik, 19:37:53) * AGREED: try and find a new time, revisit next week. (nirik, 19:42:55) * Updates policy / Vision implementation status (nirik, 19:43:23) * AGREED: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft is approved (nirik, 19:58:14) * ACTION: nirik will announce new policy (nirik, 20:00:58) * http://fedoraproject.org/wiki/Features/DNSSEC_on_workstations (nirik, 20:05:18) * LINK: http://fedoraproject.org/wiki/Releases/15/Schedule (nirik, 20:10:52) * LINK: https://fedoraproject.org/wiki/Releases/15 (drago01, 20:10:55) * #469 App install related issues (nirik, 20:12:46) * LINK: http://linux.mirrors.es.net/fedora//updates/testing/14/i386/repodata/ (skvidal, 20:36:20) * AGREED: ship the package and agree to switch to the repodata version if/when. (nirik, 20:54:57) * #467 Make Feature Freeze happen sooner. (nirik, 20:59:32) * revist next week, ask submitter for a concrete thing to vote on (nirik, 21:24:12) * #471 FPC Draft for Ratification (nirik, 21:24:19) * LINK: https://fedorahosted.org/fpc/ticket/12 although hey-o tl;dr (ajax, 21:26:14) * AGREED: this is approved (nirik, 21:31:10) * Open Floor (nirik, 21:31:13) * LINK: https://fedoraproject.org/w/index.php?title=User%3AKevin%2FUpdates_Policy_Draftdiff=199546oldid=199095 (nirik, 21:31:39) Meeting ended at 21:35:19 UTC. Action Items * nirik will announce new policy Action Items, by person --- * nirik * nirik will announce new policy * **UNASSIGNED** * (none) People Present (lines said) --- * nirik (150) * pjones (109) * hughsie (74) * skvidal (63) * ajax (52) * mjg59 (51) * notting (37) * Oxf13 (29) * SMParrish (21) * mclasen (20) * geppetto (16) * zodbot (11) * drago01 (11) * cwickert (9) * jsmith (2) * lmacken (1) * kylem (0) -- 19:30:01 nirik #startmeeting FESCO (2010-09-28) 19:30:01 zodbot Meeting started Tue Sep 28 19:30:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:30:01 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 19:30:01 nirik #meetingname fesco 19:30:01 nirik #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59 19:30:01 nirik #topic init process 19:30:01 zodbot The meeting name has been set to 'fesco' 19:30:01 zodbot Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones 19:30:28 pjones good lord, my local machine's time drifts a lot. 19:31:01 nirik time flies when you're having fun? ;) 19:31:17 mjg59 Afternoon 19:31:44 pjones problem seems to be that it can't talk to anything that's part of fedora.pool.ntp.org 19:31:48 pjones oops 19:31:51 * nirik waits for folks to wander in. 19:31:56 * notting is here 19:32:09 notting nirik: should we handle kylem's situation as a first item? 19:32:17 nirik notting: yeah, likely so. 19:32:25 * SMParrish here 19:32:59 nirik ok, thats 5 of us, so I guess we could go ahead and start in. 19:33:13 mjg59 ajax ought to be around 19:33:27 ajax he is. 19:33:28 nirik mclasen was just around in devel. 19:33:46 mclasen I'm here, no ? 19:34:04 nirik yeah, just didn't see if you were active. ;) 19:34:28 nirik #topic Kylem unable to attend meetings in this timeslot 19:34:32 * hughsie is here too 19:34:40 nirik so, kylem has a conflict with this time for the next 10 weeks. 19:34:50 pjones so, the problem is kylem has class on tuesday afternoons? 19:34:58 pjones that is, it's not just this timeslot, right? 19:35:02 nirik we could try and move the meeting time, but as I recall we had not much choice for times everyone could make. 19:35:05 nirik yes. 19:35:26 notting have other people's availability changed since we first did this? 19:35:31 mclasen we could just rescan for another time ? 19:35:48 * mclasen has had some variation in afternoon unavailability 19:35:52 * nirik is available most times (still) 19:35:54 mjg59 Ok 19:36:02 pjones I think it mostly depends on mclasen? though the later parts of tuesday afternoon are now available for me (and monday has become less available) 19:36:08 mjg59 Maybe we should do another run of scheduling and see if we can improve things 19:36:13 pjones sounds like it 19:36:27 nirik I could possibly dig up the old one and people could just adjust it. 19:36:36 SMParrish I have some flexibility 19:36:37 pjones yeah 19:36:50 mclasen nirik: sounds like its worth a try 19:37:21 nirik it seems to be gone. ;( 19:37:51
Re: REVIEW/RFC: https://fedoraproject.org/wiki/User:Kevin/Updates_Policy_Draft
On Tue, 28 Sep 2010 18:45:11 +0200 Jaroslav Reznik jrez...@redhat.com wrote: Ok - that's one problem - we sucks in selective updates and information for users. Other could be - change release scheme: 1. very similar to current one - rawhide, Fn, Fn-1 * rawhide - really raw development platform * Fn - live release, similar to current state but more testing (proventesters, autoqa) * Fn-1 - do not touch, even more strict rules Thats what https://fedoraproject.org/wiki/Updates_Policy already attempts to impress on maintainers. advantage - nearly no changes in our current workflow, compromise for more groups, Fn is live, hq updates but sometimes makes things more unstable, collateral damage... but slowing down in time (no big updates Fn+1 - 1 month?), once it hits Fn - it's really fresh but another 6 months of development - more stable, more bugfixes, happier users. With current policy - we have two frozen releases, no devs care anymore, dead and stable in terms - not touched not in functionality. I'm not sure I follow... you mean rawhide is the way it is now, but F13 would be still open to major changes? 2. big change * devel branches - now with GIT - every new feature should be developed in separate branch - map it to development instance of Koji... * rawhide - merged devel branches with integration testing - fresh one, similar to current Fedora release - can be used by developers and power users - sometimes broken by updates but they know how to deal with this breakage... I'm not sure how this is different than current rawhide? * Fn - released one, strict update policy, service packs? - so faster update cycle? maybe I'm not sure how this is different than the proposed stable updates policy? 3. combination - I'd like to see devel branches, really and I like Fn Fn-1 flexibility from the first example! As I already said - I'm not against making Fedora better and more stable. I just think it's more complicated than just this less updates = stable experience = more users ;-) I agree, but I don't think thats the entire thing thats being proposed. ;) I think it's also more testing, more consideration of _when_ we should do an update, etc. 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
Kevin Fenzi wrote: On Tue, 28 Sep 2010 09:17:23 +0200 Dodji Seketeli do...@redhat.com wrote: Brandon Lozza bran...@pwnage.ca writes: Most of us KDE users want deliberate visible changes to the user. That's the point in having the latest version. Sorry if this has been already answered before, but what about having the KDE SIG issuing its own respin'ed DVDs, along with its own backport repo for stable versions that have been released? Thats an idea. I don't know how practical it is, but it's been suggested before. I have done that on occasion in the past, but these have generally been unofficial/unbranded respins, since the backported builds were done outside of fedora infrastructure. It also requires that other things don't break the creation of live images (like livecd-tools, udev, NetworkManager and friends now on f13, for gory details and a fun read, https://bugzilla.redhat.com/show_bug.cgi?id=624028 ) -- Rex -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi v0.7.9 deployed
Michael Schwendt wrote: https://admin.fedoraproject.org/updates/xorg-x11-drv-geode-2.11.9-1.fc14 This update is the perfect example for how this new update policy is completely broken and just cannot work. A bugfix is now being held up for almost a month just because there's no proventester with the required hardware. The only suggestion I can give is to just +1 the update to have it finally go out as it should. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: bodhi v0.7.9 deployed
On Wed, 2010-09-29 at 05:51 +0200, Kevin Kofler wrote: Michael Schwendt wrote: https://admin.fedoraproject.org/updates/xorg-x11-drv-geode-2.11.9-1.fc14 This update is the perfect example for how this new update policy is completely broken and just cannot work. Again, you're extrapolating way too far from a single problem case. The problem is simply that we have the xorg-x11-drivers metapackage which requires every single X driver and is in the critpath. There's various ways we could adjust this so it's no longer the case. It's hardly something that renders an entire policy invalid. A bugfix is now being held up for almost a month just because there's no proventester with the required hardware. The proventesters are not an immutable set. There's certainly people who have the hardware - anyone with an XO, and I see enough of them at FUDCons. All we need is for one of them to sign up to be a proventester. This isn't impossible either. -- 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: bodhi v0.7.9 deployed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/28/2010 09:31 PM, Adam Williamson wrote: On Wed, 2010-09-29 at 05:51 +0200, Kevin Kofler wrote: Michael Schwendt wrote: https://admin.fedoraproject.org/updates/xorg-x11-drv-geode-2.11.9-1.fc14 This update is the perfect example for how this new update policy is completely broken and just cannot work. Again, you're extrapolating way too far from a single problem case. The problem is simply that we have the xorg-x11-drivers metapackage which requires every single X driver and is in the critpath. There's various ways we could adjust this so it's no longer the case. It's hardly something that renders an entire policy invalid. A bugfix is now being held up for almost a month just because there's no proventester with the required hardware. The proventesters are not an immutable set. There's certainly people who have the hardware - anyone with an XO, and I see enough of them at FUDCons. All we need is for one of them to sign up to be a proventester. This isn't impossible either. Also in situations like these it should be possible for proven tester to give karma by proxy, seeking out somebody with the hardware to test it. - -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkyiw3EACgkQ4v2HLvE71NXr1QCdFR37+igMB8WS9Tek+0FgnVNX +Y0An3WzkLIvDC6srAZABVw7bOpbJAHa =RUDn -END PGP SIGNATURE- -- 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
On 09/28/2010 05:38 AM, Ralf Corsepius wrote: 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. I just commited a patch which hopefully fixes these issues into git and summitted these packages for fc13 and fc14 testing. 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
[perl-POE/el4/master] Fixed .spec for .el4.
commit ed65e211deb5209909c7e50f23e044b8fb4bd2fb
Author: Steve Traylen steve.tray...@cern.ch
Date: Tue Sep 28 23:57:58 2010 +0200
Fixed .spec for .el4.
perl-POE.spec | 26 +++---
1 files changed, 15 insertions(+), 11 deletions(-)
---
diff --git a/perl-POE.spec b/perl-POE.spec
index b2bcdc2..fb305f9 100644
--- a/perl-POE.spec
+++ b/perl-POE.spec
@@ -1,6 +1,6 @@
Name: perl-POE
Version: 1.269
-Release: 1%{?dist}
+Release: 2%{?dist}
Summary: POE - portable multitasking and networking framework for Perl
Group: Development/Libraries
@@ -32,12 +32,13 @@ BuildRequires: perl(Test::Pod)
BuildRequires: perl(Test::Pod::Coverage)
BuildRequires: perl(Module::Build)
-BuildRequires: perl(Storable) = 2.16
+BuildRequires: perl(Storable)
BuildRequires: perl(Errno) = 1.09
-BuildRequires: perl(IO::Handle) = 1.27
+BuildRequires: perl(IO::Handle)
BuildRequires: perl(Socket) = 1.7
-BuildRequires: perl(IO::Tty) = 1.08
-BuildRequires: perl(POE::Test::Loops) = 1.022
+BuildRequires: perl(IO::Tty)
+# Removed for bootstrap.
+#BuildRequires: perl(POE::Test::Loops) = 1.022
BuildRequires: perl(POSIX) = 1.02
BuildRequires: perl(File::Spec) = 0.87
BuildRequires: perl(Exporter)
@@ -52,9 +53,9 @@ Requires: perl(Carp)
Requires: perl(Errno) = 1.09
Requires: perl(Exporter)
Requires: perl(File::Spec) = 0.87
-Requires: perl(IO::Handle) = 1.27
-Requires: perl(IO::Tty) = 1.08
-Requires: perl(POE::Test::Loops) = 1.022
+Requires: perl(IO::Handle)
+Requires: perl(IO::Tty)
+#Requires: perl(POE::Test::Loops) = 1.022
Requires: perl(POSIX) = 1.02
Requires: perl(Socket) = 1.7
Requires: perl(Storable) = 2.16
@@ -80,8 +81,8 @@ possible to use POE at varying levels of abstraction.
# make rpmlint happy...
chmod -c -x examples/*
-find t/ -type f -exec chmod -c -x {} +
-find t/ -type f -name '*.t' -exec perl -pi -e 's|^#!perl|#!%{__perl}|' {} +
+find t/ -type f -exec chmod -c -x {} \;
+find t/ -type f -name '*.t' -exec perl -pi -e 's|^#!perl|#!%{__perl}|' {} \;
%build
%{__perl} Makefile.PL INSTALLDIRS=vendor --default
@@ -96,7 +97,7 @@ make %{?_smp_mflags}
rm -rf %{buildroot}
make pure_install PERL_INSTALL_ROOT=%{buildroot}
-find %{buildroot} -type f -name .packlist -exec rm -f {} +
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
find %{buildroot} -type d -depth -exec rmdir {} 2/dev/null ';'
%{_fixperms} %{buildroot}/*
@@ -129,6 +130,9 @@ rm -rf %{buildroot}
%changelog
+* Tue Sep 28 2010 Steve Traylen cw...@alumni.drew.edu 1.269-2
+- Fix .spec file to work on .el4.
+
* Sun Sep 27 2009 Chris Weyl cw...@alumni.drew.edu 1.269-1
- update filtering...
- auto-update to 1.269 (by cpan-spec-update 0.01)
--
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-POE/el4/master] Correct email addres.
commit 9d933efc0b3f4254a7e402f88e850b90f5cd0afc
Author: Steve Traylen steve.tray...@cern.ch
Date: Wed Sep 29 00:04:43 2010 +0200
Correct email addres.
perl-POE.spec |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
---
diff --git a/perl-POE.spec b/perl-POE.spec
index fb305f9..cd0c7ba 100644
--- a/perl-POE.spec
+++ b/perl-POE.spec
@@ -1,6 +1,6 @@
Name: perl-POE
Version: 1.269
-Release: 2%{?dist}
+Release: 3%{?dist}
Summary: POE - portable multitasking and networking framework for Perl
Group: Development/Libraries
@@ -130,6 +130,9 @@ rm -rf %{buildroot}
%changelog
+* Tue Sep 28 2010 Steve Traylen steve.tray...@cern.ch 1.269-3
+- Correct email address in this changelog.
+
* Tue Sep 28 2010 Steve Traylen cw...@alumni.drew.edu 1.269-2
- Fix .spec file to work on .el4.
--
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: [389-devel] 1.2.6-1 crash
The stack traces from the ns-slapd core would be very helpful. 1. login as root 2. ps -ef | grep ns-slapd ldapuser 27526 1 0 Sep24 ?00:02:21 ./ns-slapd -D ... 3. attach the process to gdb # gdb /usr/sbin/ns-slapd 27526 gdb continue 4. start the LDAP intensive application Hopefully, it makes ns-slapd crash. Then, run bt command: gdb thread apply all bt Thanks, --noriko On 9/28/10 8:38 PM, Gary Morris wrote: ok.. it pulled 389-ds-base-1.2.6-2.fc13.x86_64.. is that ok or do i need to be on 1.2.6-1? On 1.2.6-2 I'm having the same problem. As soon as I start an application that is ldap intensive, the directory server crashes real quick. No errors of any sort reported. On Tue, Sep 28, 2010 at 11:16 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: Gary Morris wrote: Hi guys.. i'm running 389-ds-base-1.2.6-1.fc13.x86_64 and the server is crashing repeatedly, mostly under load. There are about 390,000 ldap entries in the database. I tried installing on a couple of different servers (Fedora 13) with the same problem. The problem does not seem to be happening on 1.2.6-0.1. I would be happy to send you more details on what is causing the crash if I could figure out how to do that. When I put any load on the server, it crashes, and often crashes before it can even fully start. It does not seem to crash when I turn on the heavy debugging, but then again, performance is very slow on full debug. If anyone has some suggestions on what I can do to give more information, i'd be happy to. There were a couple of crashing bugs that have been fixed in 1.2.6.1-1 - now available in the Testing repos. Please try to install 389-ds-base-1.2.6.1-1 from the updates-testing repo and see if that fixes your problem. -gary -- 389-devel mailing list 389-devel@lists.fedoraproject.org mailto:389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org mailto:389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
