Re: [fedora-arm] Fedora ARM VFAD - May 11th - 12pm (EDT)
On Sat, May 12, 2012 at 2:36 AM, DJ Delorie wrote: > >> Right- followup question: Is Firefox what we want in the X images? > > What's the default browser for x86 ? Firefox. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
F-17 Branched report: 20120512 changes
Compose started at Sat May 12 08:15:18 UTC 2012 Broken deps for x86_64 -- [LuxRender] LuxRender-blender-0.8.0-13.fc17.x86_64 requires blender(ABI) = 0:2.61 [aeolus-conductor] aeolus-conductor-0.4.0-2.fc17.noarch requires rubygem(fastercsv) aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc17.noarch requires ruby-nokogiri [dh-make] dh-make-0.55-4.fc17.noarch requires debhelper [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17 [gnome-do-plugins] gnome-do-plugins-banshee-0.8.4-8.fc17.x86_64 requires mono(Banshee.CollectionIndexer) = 0:2.2.0.0 [gorm] gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20 gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23 gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-gui.so.0.20()(64bit) gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libgnustep-base.so.1.23()(64bit) [matreshka] matreshka-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-fastcgi-0.1.1-9.fc17.i686 requires libgnarl-4.6.so matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-fastcgi-0.1.1-9.fc17.x86_64 requires libgnarl-4.6.so()(64bit) matreshka-sql-core-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-core-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-postgresql-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-postgresql-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) matreshka-sql-sqlite-0.1.1-9.fc17.i686 requires libgnat-4.6.so matreshka-sql-sqlite-0.1.1-9.fc17.x86_64 requires libgnat-4.6.so()(64bit) [mcollective] mcollective-common-1.3.1-7.fc17.noarch requires ruby(abi) = 0:1.8 [moksha] moksha-0.5.0-5.fc15.noarch requires pyevent [natus] libnatus-V8-0.1.5-2.fc15.x86_64 requires libv8-3.0.0.1.so()(64bit) [ocaml-augeas] ocaml-augeas-0.4-9.fc15.x86_64 requires ocaml(runtime) = 0:3.12.0 [openvrml] libopenvrml-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_thread-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_system-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.i686 requires libboost_filesystem-mt.so.1.47.0 libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) libopenvrml-gl-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-java-0.18.8-2.fc16.x86_64 requires java-1.6.0-openjdk(x86-64) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-javascript-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-nodes-0.18.8-2.fc16.x86_64 requires libboost_filesystem-mt.so.1.47.0()(64bit) openvrml-xembed-0.18.8-2.fc16.x86_64 requires libboost_thread-mt.so.1.47.0()(64bit) openvrml-xembed-0.18.8-2.fc16.x86_64 requires libboost_system-mt.so.1.47.0()(64bit) openvrml-xembed-0.1
enable-languages=c++ in cross-gcc
Hi, I'm trying to build brickOS (alternative OS for the LEGO Mindstorms RCX unit) on fedora (rawhide), which requires the c and c++ h8300 cross compilers. In fedora however, cross-gcc is build only with enable-languages=c. Is there a particular reason for this? Thanks! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rawhide report: 20120512 changes
Compose started at Sat May 12 08:15:20 UTC 2012 Broken deps for x86_64 -- [389-admin] 389-admin-1.1.28-1.fc18.i686 requires libicuuc.so.48 389-admin-1.1.28-1.fc18.i686 requires libicui18n.so.48 389-admin-1.1.28-1.fc18.i686 requires libicudata.so.48 389-admin-1.1.28-1.fc18.x86_64 requires libicuuc.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicui18n.so.48()(64bit) 389-admin-1.1.28-1.fc18.x86_64 requires libicudata.so.48()(64bit) [389-adminutil] 389-adminutil-1.1.15-2.fc17.i686 requires libicuuc.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicui18n.so.48 389-adminutil-1.1.15-2.fc17.i686 requires libicudata.so.48 389-adminutil-1.1.15-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-adminutil-1.1.15-2.fc17.x86_64 requires libicudata.so.48()(64bit) [389-dsgw] 389-dsgw-1.1.9-2.fc17.x86_64 requires libicuuc.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicui18n.so.48()(64bit) 389-dsgw-1.1.9-2.fc17.x86_64 requires libicudata.so.48()(64bit) [aeolus-all] aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-doc = 0:0.4.0-2.fc17 aeolus-all-0.4.0-2.fc17.noarch requires aeolus-conductor-daemons = 0:0.4.0-2.fc17 [aeolus-configserver] aeolus-configserver-0.4.5-1.fc18.noarch requires ruby-nokogiri [axis2c] axis2c-1.6.0-4.fc17.i686 requires httpd-mmn = 0:20051115-x86-32 axis2c-1.6.0-4.fc17.x86_64 requires httpd-mmn = 0:20051115-x86-64 [bibletime] bibletime-2.9.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit) bibletime-2.9.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit) [boost141] boost141-graph-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-graph-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-graph-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-graph-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) boost141-regex-1.41.0-2.fc17.i686 requires libicuuc.so.48 boost141-regex-1.41.0-2.fc17.i686 requires libicui18n.so.48 boost141-regex-1.41.0-2.fc17.x86_64 requires libicuuc.so.48()(64bit) boost141-regex-1.41.0-2.fc17.x86_64 requires libicui18n.so.48()(64bit) [couchdb] couchdb-1.1.1-1.fc18.x86_64 requires libicuuc.so.48()(64bit) couchdb-1.1.1-1.fc18.x86_64 requires libicui18n.so.48()(64bit) couchdb-1.1.1-1.fc18.x86_64 requires libicudata.so.48()(64bit) [dustmite] dustmite-1-4.20120304gitcde46e0.fc17.x86_64 requires libphobos2-ldc.so()(64bit) [evolution-couchdb] evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-cal-1.2.so.15()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libedata-book-1.2.so.13()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libecal-1.2.so.11()(64bit) evolution-couchdb-0.5.91-10.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [evolution-rss] 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libedataserverui-3.0.so.1()(64bit) 1:evolution-rss-0.3.91-1.fc18.x86_64 requires libcamel-1.2.so.33()(64bit) [gauche-gl] gauche-gl-0.5.1-3.fc17.x86_64 requires libgauche-0.9.so.0.2()(64bit) [gauche-gtk] 1:gauche-gtk-0.6-0.4.20110725git598828842a339.fc17.x86_64 requires libgauche-0.9.so.0.2()(64bit) [gcc-python-plugin] gcc-python2-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python2-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-debug-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 gcc-python3-plugin-0.9-2.fc18.x86_64 requires gcc = 0:4.7.0-4.fc18 [ghc-wai-extra] ghc-wai-extra-0.4.6-3.fc18.i686 requires libHSzlib-enum-0.2.1-ghc7.4.1.so ghc-wai-extra-0.4.6-3.fc18.i686 requires libHSzlib-bindings-0.0.3.2-ghc7.4.1.so ghc-wai-extra-0.4.6-3.fc18.i686 requires ghc(zlib-enum-0.2.1-55af94f47edaf6ddd74e441a7a34ef7e) ghc-wai-extra-0.4.6-3.fc18.i686 requires ghc(zlib-bindings-0.0.3.2-3d82a54b78146286e86c5a9fa9085ef2) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires libHSzlib-enum-0.2.1-ghc7.4.1.so()(64bit) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires libHSzlib-bindings-0.0.3.2-ghc7.4.1.so()(64bit) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires ghc(zlib-enum-0.2.1-6264df6f05d62c31c73f13219fe69f53) ghc-wai-extra-0.4.6-3.fc18.x86_64 requires ghc(zlib-bindings-0.0.3.2-d83646b762e4c3d5f1dcf4b8665bb1c5) ghc-wai-extra-devel-0.4.6-3.fc18.i686 requires ghc-devel(zlib-enum-0.2.1-55af94f47edaf6ddd74e441a7a34ef7e) ghc-wai-extra-devel-0.4.6-3.fc18.i686 requires ghc-devel(zlib-bindings-0.0.3.2-3d82a54b78146286e86c5a9fa9085ef2) ghc-wai-extra-devel-0.4.6-3.fc18.x86_64 requires ghc-devel(zlib-enum-0.2.1-6264df6f05d62c31c73f13219fe69f53)
Installer unable to detect Geforce GTX 460 v2
I have submitted a bug report[1] related to nouveau driver. The installer is unable to detect Nvidia Geforce GTX 460 v2 [2] which is different from the original Nvidia Geforce GTX 460, forcing the use of vesa driver. As a result, the screen is black so I cannot provide a xorg.log report let alone smolt hardware profile. Ref: [1] https://bugzilla.redhat.com/show_bug.cgi?id=821180 [2] http://geforce.com/hardware/desktop-gpus/geforce-gtx-460/specifications -- Luya Tshimbalanga Graphic& Web Designer E: l...@fedoraproject.org W: http://www.thefinalzone.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
12.1.0 devel build 10 released, for the XO-1, XO-1.5 and XO-1.75
The "Just when you thought it was safe to go back in the water... " release. This is the end of the development cycle. We're now headed into the stabilisation and bug fixing phase. http://wiki.laptop.org/go/12.1.0/Release_plan Fixed bugs: #11796 XO-1 os8 (12.1.0) - 'rpm' fails to run #11766 systemd doesn't remount / RO on shutdown #10865 Help activity has old toolbar #11718 Help activity does not start #11710 os4: hostname is none #11286 powerd should not suspend on open external serial devices #11610 Time rollback disables powerd's power button control #11740 powerd: usb-inhibits broken #11807 powerd: convert xo-1 usage of /sys/power/wlan-enabled to rfkill #11808 powerd: keyboard wakeups can't be disabled #11791 Scratch plugins on 12.1.0 on XO-1.75 are x86 again #11827 Remove Sugar Keyboard Settings control panel (12.1.0) #6109 Default zoom of 71% (fit to screen) not part of default zoom list #11822 Add DisplayLink (USBVGA) support Activity changes: -Abacus-34 -Browse-136 -Calculate-39 +Abacus-35 +Browse-137 +Calculate-40 -Clock-7 +Clock-8 -Finance-6 +Finance-7 -Help-13 +Help-14 -Moon-13 -Paint-42 +Moon-14 +Paint-43 -Record-95 +Record-96 -Scratch-19 +Scratch-22 +SimpleGraph-3 -Write-78 +Write-79 Download from: http://build.laptop.org/12.1.0/os10/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide ext4/virtio FS performance hit (10x slower) ?
Josh Boyer wrote: > On Mon, May 7, 2012 at 8:43 AM, Jim Meyering wrote: >> Today I noticed that some tests from coreutils' test suite >> were taking far longer than they used to on rawhide. >> For example, run this command in an empty directory: >> >> seq 20|env time xargs touch >> >> it takes < 5s on F17 3.3.4-1.fc17.x86_64 ext4/sdb8/SSD, yet >> it takes 47s on rawhide 3.4.0-0.rc5.git5.1.fc18.x86_64 ext4/vda1/SSD >> >> 10x performance hit... ouch. >> >> Does anyone know why? > > Rawhide has all the kernel debug options turned on. It isn't > worthwhile doing a comparison when those are enabled. You could try > again with the first -rc6 build that shows up, as that will have the > options disabled. Hi Josh, I've just rerun the test with 3.4.0-0.rc6.git1.1.fc18.x86_64, and it takes just as long, so the hit is *not* due to debug options: $ seq 20|env time xargs touch 0.17user 41.98system 0:48.22elapsed 87%CPU (0avgtext+0avgdata 1424maxresident)k 88inputs+0outputs (0major+4502minor)pagefaults 0swaps -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide ext4/virtio FS performance hit (10x slower) ?
On Sat, May 12, 2012 at 11:04 PM, Jim Meyering wrote: > Josh Boyer wrote: > >> On Mon, May 7, 2012 at 8:43 AM, Jim Meyering wrote: >>> Today I noticed that some tests from coreutils' test suite >>> were taking far longer than they used to on rawhide. >>> For example, run this command in an empty directory: >>> >>> seq 20|env time xargs touch >>> >>> it takes < 5s on F17 3.3.4-1.fc17.x86_64 ext4/sdb8/SSD, yet >>> it takes 47s on rawhide 3.4.0-0.rc5.git5.1.fc18.x86_64 ext4/vda1/SSD >>> >>> 10x performance hit... ouch. >>> >>> Does anyone know why? >> >> Rawhide has all the kernel debug options turned on. It isn't >> worthwhile doing a comparison when those are enabled. You could try >> again with the first -rc6 build that shows up, as that will have the >> options disabled. > > Hi Josh, > > I've just rerun the test with 3.4.0-0.rc6.git1.1.fc18.x86_64, This one has debug options enabled; 3.4.0-0.rc6.git0.1 is the one without debug options. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide ext4/virtio FS performance hit (10x slower) ?
Am 12.05.2012 23:38, schrieb drago01: >> I've just rerun the test with 3.4.0-0.rc6.git1.1.fc18.x86_64, > > This one has debug options enabled; 3.4.0-0.rc6.git0.1 is the one > without debug options. how can someone find out if it is a debug-kernel? even the satble ones seems to have a ton of debug options enabled especially "CONFIG_DEBUG_KERNEL=y" [root@srv-rhsoft:/boot]$ cat config-3.3.5-2.fc16.x86_64 | grep -i debug | grep "=y" CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_SLUB_DEBUG=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_XEN_DEBUG_FS=y CONFIG_X86_DEBUGCTLMSR=y CONFIG_PM_DEBUG=y CONFIG_PM_ADVANCED_DEBUG=y CONFIG_CFG80211_DEBUGFS=y CONFIG_MAC80211_DEBUGFS=y CONFIG_DEBUG_DEVRES=y CONFIG_CB710_DEBUG_ASSUMPTIONS=y CONFIG_IWMC3200TOP_DEBUGFS=y CONFIG_DM_DEBUG=y CONFIG_FIREWIRE_OHCI_DEBUG=y CONFIG_MLX4_DEBUG=y CONFIG_ATH5K_DEBUG=y CONFIG_ATH9K_DEBUGFS=y CONFIG_ATH6KL_DEBUG=y CONFIG_IWLWIFI_DEBUG=y CONFIG_IWLWIFI_DEBUGFS=y CONFIG_IWLEGACY_DEBUG=y CONFIG_IWLEGACY_DEBUGFS=y CONFIG_RT2X00_LIB_DEBUGFS=y CONFIG_SND_DEBUG=y CONFIG_SND_PCM_XRUN_DEBUG=y CONFIG_INFINIBAND_MTHCA_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG=y CONFIG_INFINIBAND_IPOIB_DEBUG_DATA=y CONFIG_DRM_NOUVEAU_DEBUG=y CONFIG_DLM_DEBUG=y CONFIG_DEBUG_FS=y CONFIG_DEBUG_KERNEL=y CONFIG_DEBUG_SHIRQ=y CONFIG_SCHED_DEBUG=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_INFO=y CONFIG_DEBUG_VM=y CONFIG_DEBUG_MEMORY_INIT=y CONFIG_DEBUG_LIST=y CONFIG_DYNAMIC_DEBUG=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_RODATA=y CONFIG_DEBUG_RODATA_TEST=y CONFIG_DEBUG_SET_MODULE_RONX=y CONFIG_DEBUG_BOOT_PARAMS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On 11/05/12 00:30, Adam Jackson wrote: > So the set of people we'd be inconveniencing is exactly the set of > people with no bandwidth and the inability to boot from anything larger > than a CD. The way forward for those cheap machines on cheap networks is to let them boot from CD but to then pull most of the installation from USB hard disk or flash. I believe that this amounts to little more than a better description in the documentation. As for your question about numbers, the "high end" machines coming through my local "PCs for the poor" refurbisher (www.aspitech.com.au) have DVD-ROM drives (ie, even those more expensive machines can't write a DVD image, but can write a CD image). So this isn't only a third-world issue, but one faced by anyone trying to get Linux running whilst on low income. -- Glen Turner www.gdt.id.au/~gdt -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide ext4/virtio FS performance hit (10x slower) ?
On Sun, May 13, 2012 at 00:00:24 +0200, Reindl Harald wrote: Am 12.05.2012 23:38, schrieb drago01: I've just rerun the test with 3.4.0-0.rc6.git1.1.fc18.x86_64, This one has debug options enabled; 3.4.0-0.rc6.git0.1 is the one without debug options. how can someone find out if it is a debug-kernel? even the satble ones seems to have a ton of debug options enabled especially "CONFIG_DEBUG_KERNEL=y" You can look at the changelog for the build. Current practice is that the first build for a particular rc is a nodebug build. The package set is also different. The debug builds don't include an update of kernel-doc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default media size [Was: Proposed F18 feature: MiniDebugInfo]
On Thu, May 10, 2012 at 11:00:48AM -0400, Adam Jackson wrote: > So the set of people we'd be inconveniencing is exactly the set of > people with no bandwidth and the inability to boot from anything larger > than a CD. Not only that - the people who have no bandwidth, the inability to boot from anything larger than a CD and no USB ports that can be bootstrapped from a bootloader sitting on a CD or floppy. USB has been required by Microsoft's logo program since 1999 and was effectively ubiquitous on Pentium 2 before that, so the set of hardware we're ruling out is at least 13 years old and more realistically probably 15. We've already dropped support for x86 hardware that was in production more recently than that. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/11/2012 02:16 AM, Jon Masters wrote: > On 05/10/2012 04:56 AM, David Airlie wrote: >> Don't confuse llvm and clang, llvm has no equivalent in gcc >> world, clang is a C compiler like gcc that uses llvm tech. > > Right so I wasn't confusing these :) However, we package both > together and for ease of discussion many folks are going to think > of it as a gcc alternative (aside from the specific gfx situations > you and ajax have). > > My main concern was potential for growing use beyond that. I made > an analogy about glibc to which I accept ajax's response that > they're trying to reconcile with eglibc, but it's more the general > concept I was getting at. Let me avoid a specific example because > someone will find a way to find a hole in it :) Instead, my stance > is we want to be very careful about unsupportable use of LLVM. I've > filed a ticket with FESCo so hopefully there can be some debate as > to acceptable use :) > >> It probably makes sense that one of myself, ajax or glisse help >> out packaging llvm, but we aren't the most reliable people in >> terms of spare time to commit. > > Right. You guys have various incentives to care about specific use > of LLVM itself so I'm sure it will always be supported to some > level, but for the other piece - clang+LLVM, etc. - to grow further > use in the distro (in displacement of gcc) I feel we'd need to have > actual RH staff to support it that I don't think we have any plans > to have. So I want to cut this off at the pass before we blink and > we have a problem. > Maybe we should draw more of a distinction between LLVM and clang, and use ExclusiveArch: on the latter to whitelist only architectures we feel comfortable supporting? I'm at the moment not really comfortable switching LLVM to be built with Clang as the default -- given that on Linux it has a brittle dependency on specific versions of libstdc++. But we could certainly make it a switchable build-time option. Apart from the worrying test suite results on secondary archs, actually it's the libstdc++ issue that's causing the most headache. How much effort does it take to maintain a compatibility version of libstdc++? It'd make clang much more useful if we're not caught between upstream (that abandons released versions) and the Fedora GCC team's fast update cycles. Thanks, - -- Michel Alexandre Salim Fedora Project Contributor: http://fedoraproject.org/ Email: sali...@fedoraproject.org | GPG key ID: A36A937A Jabber: hir...@jabber.ccc.de | IRC: hir...@irc.freenode.net () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPr0TxAAoJEEr1VKujapN6uZsIAIGhhi29Z81Ko9ayvsYqijfR b7lpEwHihJBETbsFrP5zxqAIwdr5lIvE+Ox6thK9RIHdpICIurwO9rWQ0pparBqf JLcsLeYfm96P7uoTWkjdwJTs9KHvntLtXJLek40vGq74vX43ysnNuI8vs2DqN0zB 8W10OIQfj1G7dw9tDtQjDKXZLc3mIki3lAAUesv78oSZNdFjkv28Go8K+Fku27uU XQAmK3SzIApvSPAvjuemDruwU9M2TwXmVsUDlNLtI/LYRZfm1NikX+BfP/bNCelj 51aP1livuXdhqndrEMj5/6sL2V0ku1IAJtQgdutS9bgQIJzhm2E31Mr3uE3uSlM= =iiGx -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
> Maybe we should draw more of a distinction between LLVM and clang, > and use ExclusiveArch: on the latter to whitelist only architectures > we feel comfortable supporting? That would only make it worse, for surely x86-32 and x86-64 would be whitelisted, so most developers would "just use clang anyway" and not realize the problems they're causing. The issues are how to stop developers and/or packagers from arbitrarily bringing in new dependencies that (1) aren't supportable, and (2) aren't desirable, and how to decide what dependencies fit those categories. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On 05/13/2012 01:21 AM, Michel Alexandre Salim wrote: > Maybe we should draw more of a distinction between LLVM and clang, and > use ExclusiveArch: on the latter to whitelist only architectures we > feel comfortable supporting? We could. Right now, for ARM (as an example), there is really about as much representation as x86 from what I can see in terms of core arch support. I'm sure upstream bits will be pulled in, and David and ajax will do a great job - but unless I'm mistaken they're not offering to take on the task of being a architectural maintainer for core x86 code. On x86, we have Jeff's tools group within Red Hat that does an excellent job of providing all of the kinds of behind-the-scenes support that an architecture really needs. It's not just fixing build issues, or whether stuff builds on ARM - it's known how and why specific instructions are emitted and how that relates to the design. IOW it's a full time job to support something like clang at the same level that we support gcc today and I don't see that level available. Therefore, if ExclusiveArch is a solution, it ought to be ExclusiveArch: none. Instead, while I think some arches do need to be considered for exclusion - for example, if you compare the build flags for gcc and llvm+clang today for non-ARM and non-x86 you'll see various stuff on ppc/s390x that (to me) raises some concerns just in terms of the build itself - I think more this should be "ExclusivePackage". I believe one should have to make a case for growing a dependence like this within the distribution. So we need it for soft rendering? Great. That's a wonderful exception to a general rule of not requiring it. I don't mean to sound anal, but we need to stop any growing in dependence on this until we're in a position to broadly support on any arches. (it's rather like how we have core packages depending on nonsense like ruby or python in the SPEC file just to do something that a shell escape could trivially have done ten years ago - if we don't make rules to stop this growth there, we're making it much harder to bootstrap - therefore rules do matter and we need them in this case before we start growing a dependence on something as core as a new toolchain) > I'm at the moment not really comfortable switching LLVM to be built > with Clang as the default -- given that on Linux it has a brittle > dependency on specific versions of libstdc++. But we could certainly > make it a switchable build-time option. > > Apart from the worrying test suite results on secondary archs, > actually it's the libstdc++ issue that's causing the most headache. > How much effort does it take to maintain a compatibility version of > libstdc++? It'd make clang much more useful if we're not caught > between upstream (that abandons released versions) and the Fedora GCC > team's fast update cycles. I think upstream also not providing "support" is another red flag to be honest. On the secondary arch front btw, I believe we have two problems on ARM: one is some tests are failing (not unique to ARM), and two I believe I am onto a heretofore not-well-isolated general futex bug that isn't related to LLVM/clang as a package. Anyway, I don't feel in a good position to comment on the libstdc++ resolution other than to again repeat my concerns about having any growth in dependency. Obviously don't take this personally! You do a great job Michel :) But it's become clear to me that supporting a toolchain in Fedora requires a team of folks to back it up that we don't seem to have here. Jon. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Like C++? Not afraid of quirky build systems? Seeking LLVM co-maintainers
On Sun, May 13, 2012 at 01:33:46AM -0400, Jon Masters wrote: > We could. Right now, for ARM (as an example), there is really about as > much representation as x86 from what I can see in terms of core arch > support. I'm sure upstream bits will be pulled in, and David and ajax > will do a great job - but unless I'm mistaken they're not offering to > take on the task of being a architectural maintainer for core x86 code. > On x86, we have Jeff's tools group within Red Hat that does an excellent > job of providing all of the kinds of behind-the-scenes support that an > architecture really needs. It's not just fixing build issues, or whether > stuff builds on ARM - it's known how and why specific instructions are > emitted and how that relates to the design. IOW it's a full time job to > support something like clang at the same level that we support gcc today > and I don't see that level available. Which bit of this doesn't apply to *any* package requiring a niche toolchain component? It would be problematic for packages to gratuitously migrate to llvm, but packages that actually depend on its functionality are as welcome in the distribution as anything written in ADA, go, falcon, R, AGI, Pure, Q, any of the lisps or any other compiler or interpreter we ship. Some of our toolchain components are much better supported than others, and obviously relying on one of the less supported ones is risky - unless anyone's willing to do the support work, it'll go away and so will all the packages that depend on it. Any maintainer is expected to understand that risk and make an appropriate and rational choice. From a purely practical perspective, the popularity of OS X as a development platform means that we're likely to see a gradual increase in the amount of code written to assume LLVM-specific functionality. People are just going to have to cope. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
